Construir una app de delivery parece un problema de pantallas. En la práctica es un problema de coordinación. El Ing. Eliu Giraldo y el equipo de FoodTook Labs lo comprobaron con Deevery, la plataforma de delivery con video por plato que el estudio construye y opera, nacida de la operación de delivery que el equipo lleva desde 2023.
Este artículo no repite el caso técnico, que está en cómo construimos Deevery. Aquí reunimos las lecciones que sirven a una empresa de cualquier sector: una distribuidora, una clínica, una cadena de locales o una administradora de urbanizaciones.
Lección 1: cada tipo de usuario merece su propia herramienta
Deevery tiene cuatro apps propias: clientes, repartidores, portal de restaurantes y panel interno. La tentación inicial en cualquier proyecto es hacer una sola app con menús distintos según quién entra. Suele salir mal. Un repartidor en la calle y un operador frente a un escritorio necesitan cosas opuestas.
Aplicado a tu empresa: si tienes vendedores en ruta, bodega y gerencia, probablemente necesitas herramientas separadas que compartan los mismos datos. No una pantalla que intente servir a todos. Para decidir el tipo de app, revisa app nativa, híbrida o web.
Lección 2: una sola fuente de verdad, protegida
Cuatro apps solo funcionan si todas leen y escriben en el mismo lugar con las mismas reglas. En Deevery, toda acción pasa por los controles de la base de datos: funciones y reglas dentro de la base, y nada se escribe directo desde la app. Un pedido no puede saltarse un estado porque la base no lo permite, sin importar qué app lo intente.
Aplicado a tu empresa: el inventario que ve el vendedor y el que ve la bodega no pueden diferir. Si hoy cada área tiene su hoja de cálculo, el primer paso no es una app nueva, es una fuente única con reglas claras. Lo explicamos en integrar tu ERP con tus apps.
Lección 3: lo que pasa ahora vale más que el reporte de ayer
En delivery, un aviso que llega tarde es un pedido frío. Por eso Deevery trabaja con avisos en tiempo real: cuando algo cambia, el sistema avisa en ese momento, en lugar de consultar cada pocos segundos. El panel interno ve la operación como está, no como estaba.
Aplicado a tu empresa: integración y datos en tiempo real permiten decisiones informadas. Un gerente que ve las ventas del día mientras ocurren puede corregir a mediodía, no al cierre del mes. Más ejemplos en dashboards en tiempo real.
Lección 4: los errores tienen que dejar rastro
Con cuatro apps y varios tipos de usuario, algo va a fallar. La diferencia está en cuánto tarda el equipo en saber qué. En Deevery cada error deja un rastro con código, y quien da soporte lo encuentra buscándolo. A esto se suma una regla de trabajo: verificar contra el sistema real antes de afirmar que algo está resuelto.
Aplicado a tu empresa: pide a cualquier proveedor que te muestre cómo se ve un error en su sistema. Si la respuesta es un mensaje genérico sin código ni registro, cada incidente te va a costar horas. Es una de las preguntas de cómo elegir empresa de desarrollo de software.
Lección 5: la infraestructura y el diseño también se deciden
Dos decisiones que suelen quedar para el final pesan mucho en el uso diario. La primera es dónde viven la base y los servidores: en la región más cercana al usuario, para bajar la latencia, y elegida midiendo, como contamos en latencia y región en la nube. La segunda es el diseño: Deevery se diseñó para que el plato sea protagonista, sin el aspecto de plantilla que comparten tantas apps.
Qué significa para el costo de tu proyecto
Estas lecciones ya están convertidas en piezas que FoodTook Labs reutiliza. Por eso una app a medida, que en el mercado ronda los 60 mil dólares, el estudio logra hacerla con una eficiencia cercana a 20 mil. Y facilitamos el acople financiero para las empresas que desean modernizarse.
Si quieres conocer los principios completos, lee cómo diseña software el Ing. Eliu Giraldo. Y para entender por qué un estudio con productos propios entrega mejor software, revisa la tesis del fundador.