Cómo construir una app de delivery: arquitectura, features y costos

Cómo hacer una app de delivery no es una pregunta de "qué pantallas necesito", es una pregunta de arquitectura. La diferencia entre una app de delivery que aguanta el viernes de mayor demanda y una que se cae a las 8PM está en decisiones que se toman antes de escribir la primera línea de UI. Cómo vas a sincronizar el estado de un pedido entre tres apps distintas en tiempo real. Cómo vas a repartir el dinero entre plataforma, comercio y repartidor sin terminar en un Excel paralelo. Y qué stack aguanta ese tráfico sin necesitar reescritura a los seis meses. Este artículo cubre esas decisiones: arquitectura, features por rol, pagos, stack y el roadmap realista para llegar de cero a producto validado.

Si lo que buscás es el desglose de cuánto cuesta cada módulo en dólares, ya lo cubrimos en profundidad en cuánto cuesta desarrollar una app tipo Rappi o Uber — acá no repetimos esos números, nos enfocamos en cómo se construye técnicamente.

Arquitectura real-time: qué hace distinta a una app de delivery

Un CRUD tradicional lee y escribe datos cuando el usuario interactúa. Una app de delivery tiene que reflejar cambios de estado que ocurren sin que nadie toque la pantalla: el repartidor se movió 30 metros, el comercio marcó el pedido como listo, otro repartidor rechazó la asignación y hay que reasignar. Eso convierte al proyecto en un sistema de eventos, no en una app con backend.

Tres piezas hacen esa diferencia real:

• Tracking en vivo. La ubicación del repartidor tiene que actualizarse en el mapa del cliente y del admin con una latencia de segundos, no de minutos. Esto solo funciona bien con una conexión persistente (WebSockets) — hacer polling cada 5-10 segundos parece más simple al principio, pero genera carga constante en el servidor incluso sin movimiento real y drena batería del repartidor de forma agresiva.
• Matching en tiempo real. Cuando entra un pedido, el sistema tiene que decidir a qué repartidor ofrecérselo, esperar una respuesta con timeout de pocos segundos, y si rechaza o no responde, reasignar sin que el cliente note demora. Esto es una máquina de estados con colas, no un simple "asignar al más cercano".
• Estados de pedido sincronizados. Un mismo pedido tiene que verse consistente en tres pantallas simultáneamente: "confirmado" en la app del cliente, "nueva asignación" en la del repartidor, "en preparación" en la del comercio. Si el estado se desincroniza — por ejemplo el cliente ve "en camino" pero el repartidor todavía no aceptó — perdés confianza del usuario en la primera semana de uso real.

La decisión técnica que más impacto tiene acá es WebSockets (o un servicio pub/sub como Socket.io, Ably o Pusher) en vez de polling desde el día uno. Migrar de polling a WebSockets con usuarios activos en producción implica rediseñar el modelo de conexión sin cortar pedidos en curso — es una de las reescrituras más caras que vemos en diagnósticos de apps ya construidas.

Features por rol: qué necesita cada uno

Una app de delivery real son tres o cuatro productos que comparten backend pero tienen necesidades completamente distintas. Diseñar todos los roles con la misma prioridad desde el inicio es un error común — cada uno tiene un mínimo funcional diferente.

• Cliente. Explorar comercios o servicios cercanos por geolocalización, armar el pedido, elegir método de pago, seguir el estado y la ubicación del repartidor en vivo, recibir notificaciones push por cada cambio de estado, calificar al final y repetir pedidos anteriores con un tap. La fricción en el checkout es lo que más impacta conversión — cada paso extra entre "quiero pedir" y "pagué" reduce la tasa de pedidos completados.
• Repartidor. Recibir asignaciones con un timeout claro para aceptar o rechazar, navegar con GPS integrado (no un link externo a Google Maps que saca al repartidor de la app), actualizar estados con un tap (recogido, en camino, entregado) y ver ganancias y liquidaciones acumuladas. También necesita funcionar de forma aceptable con conexión intermitente: un repartidor que pierde la asignación por un corte de señal de 10 segundos es un repartidor que se va a la competencia.
• Comercio o restaurante. Recibir el pedido con una alerta sonora (no solo visual — en una cocina con ruido, una notificación silenciosa no sirve), marcar tiempos de preparación, pausar el catálogo cuando no dan abasto, ver el historial de liquidaciones y disputas. Esta app suele subestimarse en presupuesto porque "es solo un panel", pero mal diseñada genera pedidos perdidos por falta de atención.
• Admin / backoffice. Gestión de comercios y repartidores (altas, bajas, verificación), configuración de zonas de cobertura y comisiones, resolución de disputas y reembolsos, reportes financieros y de operación. Es la parte menos visible del proyecto y la más recortada en presupuestos apretados — y la que más duele recortar, porque sin ella el equipo termina operando a mano por WhatsApp en cuanto supera los 50 pedidos diarios.

Pagos y split: cómo se reparte el dinero

El cliente paga un monto único, pero ese dinero tiene que dividirse automáticamente en al menos tres destinos: la comisión de la plataforma, el pago al comercio por el producto, y el pago al repartidor por la entrega. Diseñar esto como "un webhook de la pasarela de pago" es el error que más termina en contabilidad manual paralela al sistema.

Lo que hay que resolver desde el diseño, no después:

• Retención automática de comisión. La plataforma cobra el 100% al cliente y retiene su porcentaje antes de liquidar a comercio y repartidor — no al revés. Esto evita que la plataforma dependa de que el comercio "le pague después".
• Reembolsos parciales. Si un pedido llega incompleto, ¿quién absorbe el reembolso — la plataforma, el comercio, o se prorratea? Sin esta regla definida antes de lanzar, cada disputa se resuelve manualmente y no escala.
• Propinas y bonos. Tienen que quedar separados contablemente del pago base del repartidor, porque afectan cálculos de impuestos y reportes distintos.
• Conciliación y liquidación periódica. Comercios y repartidores necesitan ver con claridad qué se les liquidó, cuándo y por qué pedidos — sin esto, las disputas de "no me pagaron lo que corresponde" consumen soporte todos los días.

En LATAM, las pasarelas típicas para este tipo de app son Wompi, ePayco o PayU para tarjetas y PSE en Colombia, Mercado Pago a nivel regional, y Stripe Connect cuando la operación necesita pagos split nativos y expansión fuera de la región. Stripe Connect en particular resuelve gran parte del split de pagos (cuentas conectadas para comercio y repartidor) de forma nativa, pero su disponibilidad y costos varían según el país — vale la pena validarlo con el proveedor antes de comprometer la arquitectura de pagos a una sola pasarela. Para el desglose de costos completo de este módulo y de los demás, retomá cuánto cuesta desarrollar una app tipo Rappi o Uber.

Stack recomendado

No hay un único stack correcto, pero sí hay combinaciones que resuelven bien los requisitos específicos de real-time, mobile y pagos de una app de delivery sin sobre-ingeniería desde el día uno.

• Backend. Node.js con NestJS o Express, o Python con FastAPI si el equipo ya tiene esa expertise — ambos manejan bien I/O concurrente para conexiones WebSocket simultáneas. PostgreSQL como base de datos, con la extensión PostGIS si el matching por geolocalización necesita queries espaciales eficientes (buscar repartidores dentro de un radio, calcular distancias reales).
• Mobile. React Native o Flutter para las apps de cliente y repartidor, priorizando un solo código base para iOS y Android salvo que haya una razón concreta de performance (por ejemplo, tracking GPS en background con optimización agresiva de batería, donde nativo puede justificarse). El panel admin normalmente va como app web — no tiene sentido nativo ahí.
• Real-time. Socket.io o WebSockets nativos sobre el backend, con Redis como capa de pub/sub y para la cola de matching (asignar pedidos a repartidores disponibles). Redis también sirve para cachear ubicaciones en vivo sin pegarle a Postgres en cada actualización de GPS.
• Pagos. Integración directa con la pasarela elegida (Wompi, Mercado Pago, Stripe Connect) más una capa propia de conciliación — nunca confiar el split completo a la lógica default de la pasarela sin lógica de negocio propia encima.
• Notificaciones push. Firebase Cloud Messaging cubre Android e iOS con una sola integración y es el estándar de facto para este tipo de producto.

Si el criterio de elección de stack te interesa más allá de esta app específica — qué mueve la aguja realmente en frontend, backend, base de datos y auth para un producto B2B — la guía qué stack elegir para un SaaS B2B en 2026 desarrolla ese criterio general.

Roadmap: de MVP a producto escalado

El orden importa tanto como las decisiones técnicas. Construir features de escala antes de validar el modelo de negocio en una ciudad es la forma más común de gastar presupuesto en infraestructura que todavía no necesitás.

• Fase 1 — MVP (8-14 semanas). Una ciudad, una categoría de servicio, matching básico por cercanía, una sola pasarela de pago, tracking en vivo funcional sin optimizaciones avanzadas de batería, panel admin con lo mínimo para operar sin Excel. El objetivo único de esta fase es confirmar que el modelo de negocio (comisión por pedido, fee de entrega) cubre los costos operativos reales con repartidores y comercios reales, no simulados.
• Fase 2 — Validación (2-4 meses de operación piloto). Con el MVP en producción en una ciudad, el foco pasa a métricas: tiempo promedio de entrega, tasa de aceptación de repartidores, costo de adquisición de comercio, retención de clientes a 30 días. Esta fase no agrega features grandes — ajusta las que ya existen según lo que muestran los datos reales de uso, y suele revelar que el algoritmo de matching necesita mejorar antes que cualquier otra cosa.
• Fase 3 — Escala (6-11 meses adicionales). Recién acá tiene sentido invertir en multi-ciudad con zonas configurables, matching avanzado con balanceo de carga y scoring de repartidores, split de pagos con conciliación automática multi-pasarela, sistema de incentivos para repartidores, y arquitectura preparada para picos de tráfico de 5-8× en horas pico. Escalar antes de este punto significa construir para una demanda que todavía no confirmaste.

El patrón que separa a los proyectos que llegan a producto maduro de los que se quedan a mitad de camino no es el tamaño del presupuesto inicial — es respetar el orden: validar arquitectura real-time y modelo de negocio en una ciudad antes de comprometer presupuesto de expansión.

Si estás evaluando construir una app de delivery o on-demand y necesitás definir arquitectura, stack y roadmap ajustados a tu operación específica, en apps a medida on-demand hacemos ese diagnóstico técnico inicial con equipo senior y presencia real en Colombia. Y si tu pregunta principal sigue siendo el presupuesto, cuánto cuesta desarrollar una app tipo Rappi o Uber tiene el desglose completo por módulo.