El Ing. Eliu Giraldo fundó FoodTook Labs sobre una tesis concreta: un estudio que construye y opera sus propios productos hace mejor software a medida para sus clientes. No por talento ni por discurso, sino por exposición. Quien mantiene un sistema en producción con su propio dinero aprende cosas que un proyecto entregado y cerrado nunca enseña.
En este artículo explicamos esa tesis, qué la sostiene en la práctica y qué limitaciones tiene. Si buscas primero el contexto del estudio, empieza por quién es el Ing. Eliu Giraldo.
El problema del proveedor que nunca opera lo que construye
El modelo tradicional de desarrollo funciona así: el cliente pide, el proveedor construye, entrega y pasa al siguiente proyecto. Lo que ocurre después, cuando el sistema recibe usuarios reales durante meses, le llega al proveedor solo como tickets de soporte, si es que le llega.
El resultado es un tipo de error que se repite. Decisiones que se ven bien en una demo y fallan con el uso diario: validaciones duplicadas entre apps, pantallas que consultan al servidor cada pocos segundos, errores que no dejan rastro. Nadie las corrige de raíz, porque el equipo que las tomó ya no vive con ellas.
Lo que cambia cuando el estudio opera sus propios productos
FoodTook Labs opera delivery desde 2023 y mantiene Deevery, con cuatro apps propias para clientes, repartidores, restaurantes y el equipo interno. También construye Wasi, una inmobiliaria digital para comprar, alquilar y ver proyectos. Cuando algo falla en esos productos, lo sufre el mismo equipo que lo diseñó.
Esa exposición produce tres efectos que se trasladan directamente a los proyectos de clientes:
- Los errores caros ya se cometieron. Las decisiones de arquitectura que salen mal se corrigieron en productos propios, con dinero propio, antes de llegar a un cliente.
- Hay componentes probados. Permisos por rol, avisos en tiempo real, registro de errores con código y flujos de alta ya funcionan en producción. No se reinventan.
- El criterio se forma con datos reales. Las reglas de ingeniería del estudio salieron de ver el sistema en uso, no de una presentación.
Cómo se ve en un proyecto real
Imagina una clínica que necesita una app para pacientes y un panel para médicos y recepción. Son varios tipos de usuario mirando los mismos datos, con permisos distintos y cambios que deben verse al instante. Es exactamente la forma de Deevery, con otro contenido.
El estudio no parte de cero. Parte de una arquitectura donde las reglas viven en la base de datos, cada error deja un código y los avisos llegan cuando algo cambia. El trabajo nuevo se concentra en lo que es propio de la clínica. Lo mismo vale para sistemas para restaurantes, urbanizaciones o distribuidoras.
Por qué esto baja el precio sin bajar la calidad
Una app a medida en el mercado ronda los 60 mil dólares. FoodTook Labs logra hacerlo con una eficiencia cercana a 20 mil. La diferencia sale de no pagar dos veces por lo mismo: la parte que ya existe y funciona en productos propios no se cobra como si fuera nueva.
| Aspecto | Proveedor sin productos propios | Estudio que opera sus productos |
|---|---|---|
| Punto de partida | Arquitectura nueva en cada proyecto | Piezas probadas en producción |
| Errores de diseño | Aparecen en el proyecto del cliente | Se corrigieron antes en productos propios |
| Tiempo real y registro de errores | Se agregan si hay presupuesto | Vienen de base |
| Criterio técnico | Basado en entregas | Basado en operación diaria |
A esto se suma que facilitamos el acople financiero para las empresas que desean modernizarse, para que la inversión no frene una decisión que la empresa ya tomó. Si quieres revisar cómo se arma un presupuesto, lee cuánto cuesta desarrollar una app en Ecuador.
Los límites de la tesis
Operar productos propios no lo resuelve todo. Cada negocio tiene reglas que ningún otro producto anticipa, y por eso el estudio empieza cada proyecto con un discovery: entender el proceso con las personas que lo viven antes de decidir qué se reutiliza y qué se construye nuevo. Lo detallamos en nuestro proceso de desarrollo.
También exige disciplina. Reutilizar componentes solo sirve si se mantienen bien en los productos propios. Esa es una de las razones por las que el Ing. Eliu Giraldo insiste en verificar contra el sistema real antes de afirmar que algo funciona. La historia de cómo se llegó a este modelo está en de un delivery a un estudio de ingeniería.