Caso de éxito · FoodTech · Marketplace móvil
Caso de éxito de app de delivery de comida: cómo creamos un agregador de reparto de comida multivendedor para una startup de FoodTech: apps nativas para clientes en iOS y Android, un panel de administración para repartidores y gestores, y un motor de rutas multimodal que mantiene los pedidos a tiempo con repartidores a pie, en bici, en patinete y en coche. Diseñado para audiencias de Estados Unidos y la Unión Europea, con un enfoque alineado con el RGPD y la CCPA y preparado para auditoría desde el primer día.
El cliente de FoodTech acudió a YuSMP Group con un problema operativo muy concreto: los repartidores elegían rutas poco óptimas, daban rodeos innecesarios, se confundían con las direcciones y perdían tiempo, lo que se traducía en entregas tardías y en una pérdida de confianza de los clientes. La visión del producto era un único agregador que reuniera restaurantes, supermercados y farmacias en un solo marketplace para el cliente y que diera a gestores y repartidores un back office operativo que realmente redujera el tiempo de entrega en lugar de limitarse a registrarlo. El comprador actual de servicios a demanda en Estados Unidos y en la Unión Europea espera un catálogo claro, el estado del pedido en tiempo real y una franja de llegada que se cumpla, y la plataforma debía ofrecer las tres cosas con repartidores a pie, en bici, en patinete y en coche en tramas urbanas densas. La construimos desde cero como una plataforma de tres lados: apps nativas para clientes en iOS y Android sobre una API de Laravel, una superficie de administración y despacho basada en React para gestores y repartidores, y un motor de rutas multimodal en el núcleo que adapta el camino óptimo al medio de transporte de cada repartidor. El desarrollo llegó a las pruebas finales previas al lanzamiento en las tiendas de aplicaciones de EE. UU. y la UE, con soporte previsto hasta la publicación y las futuras actualizaciones.
Un resumen de lo que aportó el desarrollo del agregador de reparto de comida en iOS, Android, un plano de control en Laravel y un motor de rutas multimodal.
La decisión sobre el cálculo de rutas pesa más que cualquier otra decisión de arquitectura en un agregador de reparto, porque las entregas tardías eran justo el fallo que el cliente nos contrató para corregir. Elegimos una capa de rutas multimodal a medida en lugar de una única API de indicaciones estándar porque el mismo mapa produce rutas óptimas radicalmente distintas para un repartidor a pie, una bici, un patinete eléctrico y un coche. Cada modo recibe su propio perfil de velocidad y su modelo de coste de giros, y el despachador puntúa a los repartidores candidatos según la hora estimada de llegada, la carga actual y la idoneidad del modo para la distancia de entrega; después reoptimiza de forma continua a medida que entran nuevos pedidos en la cola. Una API de indicaciones para consumidores, en cambio, asume un único modo de viaje por solicitud y no tiene noción de equidad en el despacho ni de carga de la flota, de modo que cualquier afirmación honesta sobre puntualidad tiene que razonarse en nuestra propia capa. Usamos proveedores de mapas para el grafo base de calles y rutas peatonales y superponemos nuestra lógica de puntuación y despacho, lo que mantiene el motor de rutas portable entre ciudades de EE. UU. y la UE sin reescribir el despachador.
Los SDK de reparto de marca blanca estándar se descartaron pronto: sus heurísticas de despacho son opacas, sus modelos de tiempo de viaje asumen flotas solo de coches y sus condiciones de licencia hacían incómodo el modelo de cuentas de tres lados. Construir nosotros mismos el motor de rutas sobre estándares abiertos supuso que todo el recorrido (catálogo, carrito, despacho y app del repartidor) fuera un sistema coherente y propio, entregado como parte de nuestra práctica de desarrollo de software a medida.
| Criterio | Motor de rutas a medida | API de indicaciones de un solo modo | SDK de reparto de marca blanca |
|---|---|---|---|
| Medios de transporte | A pie, bici, patinete y coche: perfiles independientes | Un modo por solicitud | Normalmente, modelo de flota solo de coches |
| Equidad y carga en el despacho | Integradas en el puntuador: ETA, carga e idoneidad del modo | Ninguna: solo indicaciones | Heurística opaca del proveedor |
| Reoptimización con nuevos pedidos | Continua mediante tareas en cola | Nueva consulta manual | Controlada por el proveedor |
| Modelo de cuentas de tres lados | Nativo: cliente, gestor y repartidor | No aplicable | Difícil de ampliar |
| Portabilidad entre ciudades de EE. UU. y la UE | Alta: se cambia el grafo del mapa y se conserva el despachador | Alta, pero sin lógica | Licencias restringidas a una región |
| Titularidad de los datos | Total: los datos de pedidos y despacho están en nuestro plano | Las consultas salen hacia el proveedor | En manos del proveedor |
| Coste a escala | Previsible: solo por consulta al grafo | Por solicitud; crece con las nuevas consultas | Comisión del proveedor por pedido |
Referencias sobre rutas: conceptos de rutas de OpenStreetMap, documentación de Apple MapKit, referencia de ubicación y mapas de Android.
La app de cliente para iOS está desarrollada en Swift, con una pantalla de inicio de marketplace que reúne restaurantes, tiendas y farmacias en una sola superficie con búsqueda, chips de categorías y un carrusel de promociones (el banner de «primera entrega gratis» es un espacio de merchandising gestionado desde la administración). El flujo de detalle de producto y carrito fue donde dedicamos un esfuerzo desproporcionado, porque los carritos abandonados son por donde la mayoría de las apps de reparto pierde ingresos sin que se note: el control de añadir al carrito, el selector de cantidad y el total del pedido en vivo se actualizan al instante sin ida y vuelta por la red, y el carrito solo se concilia con los precios del servidor en el pago. El catálogo se almacena en caché local para que la navegación sea fluida en redes móviles inestables, y la app se degrada con elegancia cuando un vendedor se desconecta a mitad de sesión.
La realización del pedido pasa al motor de rutas en cuanto el cliente lo confirma: el backend resuelve la dirección de entrega, elige al repartidor idóneo con menor ETA y envía un estado en vivo que el cliente puede seguir desde «aceptado» hasta «en camino». El mismo cliente Swift incluye los flujos de permisos de ubicación y notificaciones en contexto (se solicitan cuando el cliente sigue un pedido por primera vez, nunca en el primer arranque) para satisfacer a los revisores de la App Store y mantener honesta la experiencia de consentimiento de los usuarios de EE. UU. y la UE. Toda la superficie de iOS se entrega como parte de nuestra práctica de desarrollo de aplicaciones móviles.
La app de cliente para Android está escrita en Kotlin y comparte con iOS la misma API de Laravel, pero ajustada a la realidad de la fragmentación del parque Android. El catálogo de vendedores se muestra como una cuadrícula rápida y rica en imágenes, con valoraciones, estimaciones de tiempo de preparación y precios, respaldada por llamadas paginadas a la API y un uso intensivo de caché de imágenes para que la lista se mueva con fluidez en dispositivos de gama media de las familias Samsung, Xiaomi y Pixel. El estado del carrito, los favoritos y el pedido activo sobreviven a la finalización del proceso y a los cambios de configuración, una preocupación real en Android, donde los optimizadores de batería agresivos y los cierres por falta de memoria eliminan con frecuencia el estado de las apps en segundo plano.
El estado del pedido en tiempo real es el contrato que el cliente firma implícitamente, por lo que el cliente Android mantiene un canal en vivo con el backend para las transiciones de estado (aceptado, en preparación, recogido, en camino, entregado) y recurre a notificaciones push cuando la app está en segundo plano. Los permisos de ubicación y notificaciones se solicitan en contexto, y la pantalla de seguimiento del pedido lee del mismo flujo de estados en el que escribe la app del repartidor, de modo que cliente y repartidor nunca ven estados divergentes. El mismo equipo de ingeniería lleva iOS y Android en paralelo como parte de nuestra práctica de ingeniería iOS y Android.
El plano de control es un backend en Laravel con una superficie de administración y despacho en React para gestores de restaurantes y tiendas y para repartidores. Los gestores trabajan con un tablero de pedidos en vivo (pedidos entrantes, aceptación del vendedor, temporizadores de preparación), mientras que los repartidores disponen de una vista de despacho con su ruta asignada, la próxima recogida y la entrega al cliente. Los eventos de pedido pasan por un único flujo de estados, de modo que cliente, gestor y repartidor leen siempre el mismo estado, y el trabajo de rutas y notificaciones se ejecuta como tareas en segundo plano en cola para que las apps de cara al cliente respondan con agilidad bajo carga. La gestión de direcciones, el problema exacto que planteó el cliente, se normaliza en el servidor y se valida con el grafo del mapa antes de despachar a ningún repartidor.
En materia de privacidad, la plataforma se diseñó para alinearse con las obligaciones del RGPD para los usuarios de la Unión Europea y con las de la CCPA / CPRA para los usuarios de California y del resto de Estados Unidos. La ubicación del cliente solo se recoge mientras dura un pedido activo, la identidad de pago la gestiona el proveedor de pagos en lugar de almacenarse en el plano de pedidos y el acceso a la superficie de administración está limitado por roles, de modo que un repartidor nunca ve los datos de los clientes de otro repartidor. El diseño hace que una futura revisión independiente de preparación en materia de privacidad sea un ejercicio de documentación y no una reforma de la arquitectura.
Enfoque de cumplimiento: alineado con el RGPD · preparado para ISO 27001 · SOC 2 Type II en curso · apto para HIPAA · CCPA contemplada.
Un desarrollo en cinco fases que llevó el agregador desde la especificación del producto hasta las pruebas finales previas al lanzamiento en iOS, Android, un plano de control en Laravel y el motor de rutas.
Se mapeó el modelo de tres lados (cliente, gestor y repartidor), se identificaron los modos de fallo de las entregas tardías y la confusión de direcciones, y se fijaron de antemano el enfoque RGPD + CCPA y los requisitos de revisión de App Store y Google Play.
Esqueleto de la API de Laravel, esquema de catálogo multivendedor, motor de rutas multimodal con perfiles de velocidad por modo y puntuador de despacho según ETA, carga e idoneidad del modo.
Apps de cliente en Swift para iOS y Kotlin para Android sobre la API compartida, más las superficies de administración y despacho en React para gestores y repartidores, con carrito, pago y estado en tiempo real.
Control de acceso por roles, normalización de direcciones con el grafo del mapa, QA de los flujos de permisos, pruebas de carga de la cola de despacho y verificación del enfoque de privacidad preparado para auditoría.
Pruebas finales previas al envío a App Store y Google Play en las tiendas de EE. UU. y la UE, con soporte previsto hasta la publicación y las futuras actualizaciones.
La app para repartidores y la consola de despacho de los gestores son donde la plataforma cumple de verdad su promesa de puntualidad. Un repartidor inicia sesión, ve una ruta armada por el motor de rutas para su medio de transporte y trabaja una secuencia de recogidas y entregas con indicaciones paso a paso y transiciones de estado con un solo toque (llegado, recogido, entregado) que escriben directamente en el flujo de pedidos compartido. El despachador no se limita a asignar al repartidor más cercano: puntúa a los candidatos según la hora estimada de llegada, la carga actual y si un repartidor a pie, en bici, en patinete o en coche es la herramienta adecuada para la distancia de entrega, y luego reoptimiza al llegar nuevos pedidos para que un solo pedido nuevo no deje colgada una ruta ya eficiente. Los gestores, por su parte, usan un tablero de pedidos en React que muestra la aceptación del vendedor, los temporizadores de preparación y cualquier entrega que vaya retrasada respecto a su franja, con la normalización de direcciones que corrige la confusión original incorporada antes de despachar a ningún repartidor. Toda la superficie operativa se construyó pensando en la extensibilidad: añadir un nuevo tipo de vendedor, un nuevo medio de transporte o una nueva ciudad es un ejercicio de configuración y datos sobre los servicios de catálogo y rutas, no un lanzamiento de código; es la misma disciplina de escalado que aplicamos en nuestras hojas de ruta de cloud y DevOps.
El agregador se diseñó para las tiendas App Store y Google Play de Estados Unidos y de la Unión Europea a partir de una única base de código por plataforma. La versión en inglés está pensada para usuarios de California, Nueva York, Texas, Florida y Washington en EE. UU., y para usuarios de Países Bajos, Alemania, Francia, Irlanda y Suecia en la UE, sin una base de código distinta por región. Los flujos de consentimiento se adaptan a la región en la capa del cliente: los usuarios de la UE y el EEE reciben una pantalla de consentimiento granular al estilo del RGPD con interruptores independientes para la analítica de producto opcional, mientras que los usuarios de California reciben en el mismo flujo un aviso al estilo de la CCPA, «No vender ni compartir mi información personal». Las prácticas de tratamiento de datos están alineadas con el RGPD para los usuarios de la Unión Europea y con el mosaico de leyes estatales de privacidad de EE. UU.: CCPA / CPRA (California), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) y la CPA de Oregón. Dado que los datos de ubicación y de pedidos de los clientes están minimizados y tienen una vida corta por diseño, el cumplimiento regional se reduce en gran medida a una divulgación honesta y no a una segregación de datos por jurisdicción.
El motor de rutas es portable entre ciudades de EE. UU. y la UE por diseño: el despachador y los perfiles de velocidad por modo se mantienen constantes mientras se cambia por región el grafo de mapa subyacente, y la política de privacidad dentro de la app cita directamente las obligaciones del RGPD y las obligaciones de la CCPA de California. Tanto la clasificación por edades de App Store como la clasificación de contenido de Google Play se calibraron para un conjunto de funciones de reparto de comida y bebida, y los permisos de ubicación y notificaciones se solicitan en contexto para satisfacer a los revisores de EE. UU. y la UE. El equipo de ingeniería responsable del desarrollo trabaja en CET y sigue una jornada CET con solapamiento con la costa este de EE. UU. (9:00–13:00 ET) para las reuniones diarias, la coordinación de las revisiones de las tiendas y la respuesta a incidencias: la franja horaria que permite a un equipo de producto de EE. UU. y a uno de ingeniería de la UE compartir cuatro horas de solapamiento en directo cada día.
La hoja de ruta activa de desarrollo de software a medida del agregador incluye pedidos programados y grupales, un motor de fidelización y promociones sobre los espacios de merchandising existentes, gestión de ingresos y turnos de repartidores en la consola de despacho y seguimiento en vivo del repartidor en el mapa de la pantalla de pedido del cliente. Los planes de infraestructura incluyen más automatización de la cola de despacho, herramientas de despliegue multiciudad para que una nueva región sea un ejercicio de datos y una opción de residencia de datos que fije los datos de pedidos de la UE y EE. UU. en almacenamiento regional, todo ello integrado en la hoja de ruta de cloud y DevOps para que la plataforma escale sin fricciones de una ciudad a una presencia nacional en EE. UU. y la UE.
Si planea un agregador de reparto de comida, una app de q-commerce o cualquier producto de logística a demanda en el que la promesa de puntualidad deba sobrevivir al despacho urbano real para audiencias de EE. UU. y la UE, hemos entregado este stack de principio a fin y podemos acortar de forma notable el plazo de desarrollo. La plataforma llegó a las pruebas finales previas al lanzamiento en iOS y Android, y el equipo de ingeniería que la desarrolló forma parte de YuSMP Group. Puede ver el desarrollo de un vistazo en nuestro caso de éxito del agregador de reparto de comida. Trabajamos a precio cerrado en MVP bien acotados y con equipos de desarrollo dedicados para la entrega continua, con jornada CET y una franja garantizada de solapamiento con la costa este de EE. UU. (9:00–13:00 ET) para reuniones diarias, demos y respuesta a incidencias.
Un MVP de agregador de reparto de comida con apps para clientes en iOS y Android, un catálogo multivendedor, carrito y pago y un panel de administración básico para repartidores y gestores suele costar entre $90k y $220k. Añadir un motor de rutas multimodal para repartidores, seguimiento en tiempo real, integraciones de pago, promociones y una app independiente para repartidores lleva un marketplace completo a entre $250k y $550k. Los principales factores de coste son la lógica de rutas y despacho, el modelo de cuentas de tres lados y la sincronización en tiempo real del estado de los pedidos entre las superficies de cliente, vendedor y repartidor.
Laravel ofrece a un marketplace de reparto un backend PHP maduro y completo: colas para las tareas de despacho, un ORM expresivo para el catálogo multivendedor y una amplia reserva de profesionales que mantiene sostenible una plataforma de tres lados. React da vida a las superficies de administración de gestores y repartidores con un modelo de componentes que encaja con naturalidad en los tableros de pedidos en vivo y las consolas de despacho. La combinación mantiene la API y las herramientas web operativas en un único ecosistema bien conocido, lo que acorta el desarrollo y reduce el coste de propiedad a largo plazo para los equipos de EE. UU. y la UE que operan la plataforma.
Un motor de rutas multimodal separa el modelo de tiempo de viaje de la lógica de despacho. Cada medio de transporte (a pie, bici, patinete y coche) recibe su propio perfil de velocidad y su modelo de coste de giros, de modo que el mismo mapa produce rutas óptimas distintas para cada repartidor. El despachador puntúa a los repartidores candidatos según la hora estimada de llegada, la carga actual y la idoneidad del modo para la distancia de entrega, y después asigna y reoptimiza de forma continua a medida que llegan nuevos pedidos. Las llamadas de rutas se ejecutan como tareas en segundo plano en cola para que la app de cara al cliente siga respondiendo.
Tanto Apple como Google exigen que las apps de reparto de comida informen con claridad sobre la recogida de datos, gestionen el permiso de ubicación con una justificación de uso en primer plano y encaucen adecuadamente las compras digitales dentro de la app, permitiendo al mismo tiempo que la entrega física se pague fuera de las compras integradas. Ambas tiendas esperan una política de privacidad operativa, clasificaciones de contenido adecuadas a la edad y, para las apps que atienden a usuarios de la UE y California, un flujo de consentimiento granular que satisfaga el RGPD y la CCPA / CPRA en la misma pantalla. Los permisos de ubicación y notificaciones deben solicitarse en contexto, no en el primer arranque.
Un MVP centrado en apps de cliente para iOS y Android, un catálogo multivendedor, carrito y pago y un panel de administración básico suele tardar entre 16 y 28 semanas. Añadir un motor de rutas multimodal para repartidores, una app específica para repartidores, seguimiento en tiempo real y subsistemas de pago y promociones suma entre 8 y 14 semanas. Esto coincidía con el plazo aproximado de nueve meses de este desarrollo, que llegó a las pruebas finales previas al lanzamiento en ambas tiendas con soporte continuo previsto hasta la publicación y las futuras actualizaciones.
Casos relacionados
Marketplace de alimentación a demanda con app para repartidores, consola de operaciones y seguimiento de pedidos en vivo en EE. UU. y la UE.
Ver el caso →
Plataforma de planes de comidas y recomendador de dietas que combina recetas con reparto para usuarios de EE. UU. y la UE preocupados por su salud.
Ver el caso →
App de consumo nativa para iOS y Android con un plano de control reforzado y un enfoque preparado para auditoría en EE. UU. y la UE.
Ver el caso →
Apps nativas para iOS y Android y multiplataforma, con pipelines de publicación listos para las tiendas.
Explorar el desarrollo de aplicaciones móviles →
Plataformas a medida diseñadas para su modelo de negocio, que escalan sin problemas desde el MVP hasta millones de usuarios.
Explorar el desarrollo de software a medida →
Infraestructura escalable, pipelines de CI/CD y observabilidad para que su plataforma crezca de una ciudad a una presencia nacional.
Explorar cloud y DevOps →Cuéntenos algunos detalles y un consultor sénior le responderá en un día hábil.