Deevery es una app de delivery con video que construimos de cero y que operamos en producción desde 2023. Nació como FoodTook delivery en Samborondón y hoy evoluciona a la marca Deevery. En este caso te mostramos cómo está armada por dentro: cuatro aplicaciones sobre una misma plataforma, reglas de negocio dentro de la base de datos y avisos en tiempo real.
No vamos a darte cifras de pedidos ni de usuarios. Lo que sí podemos contarte con detalle es cómo se diseñó, qué salió bien, qué cambiamos en el camino y por qué todo eso hace que un proyecto de un cliente con FoodTook Labs cueste menos y llegue antes.
El problema: elegir comida mirando fotos que no dicen nada
Las apps de delivery se parecen mucho entre sí. Una lista de restaurantes, una foto por plato, un precio. Quien tiene hambre no decide por un listado, decide por antojo. Y una foto de catálogo rara vez provoca antojo.
La idea de partida fue simple: que el plato se vea en movimiento. Un video corto del plato real, servido, con su textura. Eso cambia la forma de elegir. Ya no buscas el restaurante y luego el plato: ves el plato y después sabes de dónde viene.
La segunda parte del problema era la búsqueda. En muchas apps escribes «smash» y te salen todos los locales de hamburguesas, más alguno que no tiene nada que ver. Queríamos que la búsqueda fuera precisa: si buscas «smash», salen smash burgers.
Qué es Deevery y cómo funciona el video
Cada plato puede tener hasta dos videos cortos. Pusimos ese límite a propósito. Dos videos bastan para mostrar el plato y, por ejemplo, el momento en que se corta o se sirve. Más que eso convierte la ficha en una galería que nadie termina de ver, encarece el almacenamiento y hace más lenta la carga en datos móviles.
La búsqueda trabaja sobre los platos, no solo sobre los nombres de los restaurantes. Eso obliga a cuidar cómo se cargan los datos de cada plato desde el inicio: nombre, tipo, ingredientes que importan. Una búsqueda precisa depende más de datos ordenados que de un algoritmo sofisticado.
Otra decisión de producto: la app se puede usar sin cuenta. Puedes explorar, mirar videos y armar tu pedido sin registrarte. La cuenta se pide solo en el momento de pedir, que es cuando de verdad hace falta saber quién eres y a dónde se entrega. Pedir registro en la primera pantalla es una de las formas más rápidas de perder a alguien que solo quería curiosear.
Cuatro aplicaciones sobre una misma plataforma
Un delivery tiene al menos cuatro tipos de usuario con necesidades muy distintas. En lugar de forzar una sola app que lo haga todo, construimos una aplicación para cada uno, todas conectadas a la misma plataforma y a la misma base de datos.
| Aplicación | Para quién | Tecnología y dispositivo |
|---|---|---|
| App de cliente | Quien pide comida | iOS nativa en SwiftUI |
| App de repartidor | El rider que recoge y entrega | App móvil dedicada |
| Portal del restaurante | El local que recibe y prepara pedidos | iPhone y iPad |
| Panel interno | El equipo de operación de Deevery | App nativa para Mac y iPad |
Que sean nativas no es un capricho. La app de cliente reproduce video todo el tiempo, y en ese uso lo nativo se nota en fluidez y en batería. El panel interno es nativo para Mac y iPad porque el equipo lo usa horas seguidas y necesita atajos, ventanas y velocidad de escritorio, no una página web dentro de un navegador. Si estás evaluando esta decisión para tu propio proyecto, la comparamos con calma en app nativa, híbrida o web.
Lo importante es que las cuatro hablan con una sola fuente de verdad. Un pedido que el cliente confirma aparece en el portal del restaurante, luego en la app del repartidor y, en todo momento, en el panel interno. Nadie copia datos de un sistema a otro.
Las reglas de negocio viven dentro de la base de datos
La base de datos de Deevery es PostgreSQL, y aquí está la decisión de arquitectura que más nos ha servido: las reglas de negocio están dentro de la base, escritas como funciones y triggers.
En la práctica eso significa que nada escribe directo en una tabla. Ni la app de cliente, ni el portal del restaurante, ni el panel interno. Todo cambio pasa por una función que valida, aplica la regla y deja registro. Si un pedido no puede pasar de «en cocina» a «entregado» sin pasar por «recogido», esa regla está en un solo lugar y vale para las cuatro aplicaciones.
- Bitácora en cada operación: cada función deja constancia de quién hizo qué y cuándo. Cuando algo sale raro, no hay que adivinar.
- Códigos de error rastreables: cuando una operación falla, devuelve un código concreto que el equipo puede buscar y entender. No un «algo salió mal» genérico.
- Una sola versión de cada regla: si cambia una política, se cambia en la base y todas las apps la respetan sin publicar actualizaciones en las tiendas.
- Menos riesgo al crecer: sumar una app nueva no obliga a reescribir validaciones. Llama a las mismas funciones.
Este enfoque tiene un costo. Exige pensar el modelo de datos antes de programar pantallas y escribir más lógica en SQL de la que muchos equipos acostumbran. Lo pagamos con gusto, porque el error típico de un sistema con varias apps es que cada una valida a su manera y los datos terminan contradiciéndose.
Avisos en tiempo real sin consultar cada pocos segundos
El panel interno necesita enterarse al instante de lo que pasa: un pedido nuevo, un comercio que cambió de estado, un repartidor que reportó algo. La solución fácil es que el panel pregunte a la base cada X segundos si hay novedades. Funciona, pero desperdicia recursos y siempre llega tarde por unos segundos.
En Deevery los avisos salen de la propia base de datos como eventos. Cuando una función cambia algo relevante, emite un evento y el panel lo recibe en ese momento. No hay consultas repetidas ni retrasos artificiales. Es el mismo principio que aplicamos cuando un cliente nos pide dashboards en tiempo real: los datos llegan cuando ocurren, para que la empresa decida con información del momento y no de hace diez minutos.
Altas controladas: la web capta, el equipo aprueba
Un restaurante o un repartidor no se da de alta solo. Primero deja un registro previo en la web con sus datos básicos. Después, el equipo interno revisa, completa la información y crea el comercio o el rider desde el panel.
Puede parecer más lento que un registro automático, pero en un negocio donde hay comida, dinero y personas entrando a domicilios, conocer a cada comercio y a cada repartidor antes de activarlos es parte del servicio. El sistema está diseñado para ese flujo: la web solo capta interesados y el panel concentra la decisión.
Lo que aprendimos construyendo y operando Deevery
- Operar enseña más que construir. Muchas decisiones correctas salieron de ver el sistema en uso real, no de la pizarra. Por eso medimos después del lanzamiento y no damos un proyecto por cerrado el día que sale a tiendas.
- Poner límites es diseño. El tope de dos videos por plato o pedir la cuenta solo al pedir son restricciones que mejoran la experiencia.
- La base de datos es el contrato. Si las reglas están ahí, las apps pueden cambiar de forma sin romper el negocio.
- El tiempo real se diseña desde la base. Los avisos por eventos salen más baratos y más rápidos que cualquier solución de consultas periódicas.
- Medir antes de decidir infraestructura. Movimos nuestra base de región después de medir la latencia real, una historia que contamos en latencia y región en la nube.
Qué se traslada a los proyectos de clientes
Deevery no es un portafolio de muestra. Es un producto que usamos todos los días, con sus problemas reales. Lo que funciona ahí se convierte en piezas que llevamos a otros proyectos:
- Arquitectura de varias apps sobre una plataforma: útil para clínicas con app de paciente y panel de médicos, cadenas con app de cliente y portal de sucursales, o urbanizaciones con app de residente y garita.
- Reglas en la base con bitácora y errores rastreables: auditoría desde el primer día, algo que pesa mucho en sistemas con dinero o datos personales.
- Avisos en tiempo real por eventos: paneles de operación que muestran lo que pasa ahora mismo.
- Apps nativas para el uso intenso: SwiftUI y Kotlin donde la fluidez importa.
- Flujos de alta controlada: captación en la web y aprobación por un equipo, cuando el negocio necesita conocer a quién activa.
Así trabajamos cada proyecto, siguiendo nuestro proceso de desarrollo en 4 fases: discovery, diseño, build con demos semanales y lanzamiento con medición.
Cuánto cuesta un desarrollo así y por qué podemos cobrar menos
Una plataforma con varias aplicaciones conectadas, reglas de negocio auditables y tiempo real suele cotizarse en el mercado en torno a USD 60.000. En FoodTook Labs, proyectos comparables quedan alrededor de USD 20.000.
La diferencia no sale de recortar calidad. Sale de este caso:
- Ya construimos y operamos nuestra propia plataforma en producción. Los errores caros de arquitectura ya los cometimos y corregimos con nuestro dinero, no con el tuyo.
- Usamos componentes probados. Autenticación, avisos en tiempo real, bitácora, manejo de errores y flujos de alta no se reinventan en cada proyecto.
- Trabajamos en ciclos cortos con demos semanales. Ves avances reales cada semana y corregimos el rumbo temprano, lo que evita semanas de retrabajo al final.
El precio final depende del alcance. Por eso empezamos con un discovery gratis: en esa conversación definimos qué necesitas y te damos un rango antes de que decidas nada. También facilitamos el acople financiero para las empresas que desean modernizarse. Si quieres ver cómo se arma un presupuesto de este tipo, revisa cuánto cuesta desarrollar una app en Ecuador.