Caso de éxito · Movilidad · Ridesharing
Caso de éxito de app de agregador de taxis: cómo lanzamos un agregador de VTC en producción —apps nativas para pasajeros y conductores más una consola de despacho en tiempo real—, creado con Laravel y PostGIS, con WebSockets que transmiten el GPS con cadencia de un segundo, verificación de documentos en el alta de conductores y registros de viajes listos para auditoría preparados para los reguladores de movilidad de EE. UU. y la UE.
Un operador regional de taxis que funcionaba con llamadas telefónicas y despacho en papel quería pasar de una sola ciudad a una cobertura nacional completa y convertirse en un agregador creíble para los mercados de movilidad de EE. UU. y la UE. La operación heredada limitaba el crecimiento al volumen que podía atender un despachador humano, dificultaba incorporar a nuevos conductores sin entregas en papel y exponía al negocio a registros de viajes incoherentes que no superarían una auditoría de un regulador en California o Alemania. El equipo necesitaba una plataforma digital en tiempo real: reserva para el pasajero con vista previa del precio, alta de conductores con verificación de documentos, una consola de despacho capaz de supervisar cientos de vehículos en varias ciudades y un ciclo de vida del viaje de principio a fin que pudiera reconstruirse línea a línea a partir de los datos. Construimos el agregador como tres productos coordinados sobre un backend compartido de Laravel + PostGIS con WebSockets que transmiten actualizaciones de posición en directo: una app nativa de pasajero en Swift, una app nativa de conductor en Kotlin y una consola de despacho en React. El resultado es una plataforma de movilidad que gestiona una flota nacional, entrega registros de viajes listos para auditoría en las jurisdicciones de EE. UU. y la UE y está posicionada para un lanzamiento acorde con las expectativas de privacidad de Estados Unidos y la Unión Europea desde el primer día.
Un resumen de lo que aportó el desarrollo de Convenient Taxi Aggregator en las superficies de pasajero, conductor y despachador sobre un backend compartido en tiempo real.
La decisión de plataforma pesa más que cualquier otra decisión de arquitectura en un desarrollo de movilidad. Elegimos Kotlin y Swift nativos frente a una solución SaaS de VTC y frente a un MVP en Flutter porque las contrapartidas encajan limpiamente con un agregador real en producción. Las soluciones SaaS atan al operador al motor de precios del proveedor, a su estructura de tarifas y a sus decisiones de residencia de datos, la última de las cuales es fatal en Estados Unidos y la Unión Europea, donde los registros de viajes están sujetos a normativas regionales de privacidad y movilidad. Flutter es excelente para apps con muchos formularios, pero paga un coste medible en la transmisión continua de GPS cada segundo y en la revisión de App Store y Google Play para justificar el permiso de ubicación en segundo plano; los servicios en primer plano de Kotlin nativo y CoreLocation de Swift nos dan un control directo y bien documentado sobre los escenarios de traspaso entre antenas que los usuarios de movilidad afrontan cada día.
El desarrollo se apoya en Apple CoreLocation en los clientes iOS de pasajero y conductor, en las API de ubicación de Android en el cliente Kotlin del conductor y en PostGIS como índice espacial del backend: una extensión espacial de código abierto y citable que nos da difusión a despachadores por teselas sin atar al operador a la nube de mapas de un proveedor.
| Criterio | Móvil nativo (Taxi Aggregator) | Stack SaaS de VTC | Flutter MVP |
|---|---|---|---|
| Latencia de la transmisión de GPS | Cadencia de publicación de ~1 segundo mediante servicio en primer plano / CoreLocation | Impuesta por el proveedor, a menudo de 5–10 s | El salto por el canal de plataforma añade ~150–300 ms de jitter |
| Encaje de la verificación de documentos | Control total del flujo KYC y de la política de retención | Flujo del proveedor; retención opaca | El puente a la cámara nativa y al OCR añade fricción |
| Encaje con los WebSockets del despachador | Difusión por teselas PostGIS a medida, control total del esquema | Temas definidos por el proveedor; no se puede dar forma a la carga útil | El despachador web es una app React aparte; la paridad con el móvil es sólida |
| Flexibilidad de precios regionales | Motor de precios propiedad del operador: tarifa dinámica, tiempo, distancia, región | Solo las primitivas de precios del proveedor | Se puede acceder al mismo motor; los ajustes de interfaz salen más rápido |
| Registros de viajes listos para auditoría | Almacén de eventos propiedad del operador, inmutable | Alojado por el proveedor; acceso solo de exportación | Mismo backend; mismas garantías |
| Comportamiento de la batería durante el turno | Servicio en primer plano / modo en segundo plano ajustado por fabricante | Envoltorio del proveedor; el fabricante lo cierra en Samsung / Xiaomi | Sigue exigiéndose el ajuste por fabricante mediante un puente nativo |
| Control de la residencia de los datos | Infraestructura propiedad del operador en regiones de EE. UU. o la UE | Solo el mapa de regiones del proveedor | Mismo control del backend; mismo enfoque |
Referencias: documentación de PostGIS, referencia de Apple CoreLocation, referencia de los servicios de ubicación de Android.
El cliente del conductor está escrito en Kotlin con Jetpack Compose para la interfaz y un servicio en primer plano basado en las API de ubicación de Android. El servicio en primer plano es obligatorio: en las familias de dispositivos Samsung, Xiaomi, OnePlus y Pixel, los optimizadores de batería agresivos cierran en pocos minutos los procesos que solo transmiten ubicación en segundo plano, rompiendo el compromiso de despacho que un conductor asume implícitamente al empezar el turno. El servicio muestra una notificación persistente mínima, solicita el permiso de ubicación en primer plano con la declaración de finalidad clara que espera el revisor de Google Play y publica la posición GPS por una conexión WebSocket persistente con una cadencia de un segundo. WorkManager se ocupa de las operaciones no urgentes —sincronización de ingresos, nueva subida de documentos, resúmenes de turno— con una semántica de reintento con espera que respeta el modo Doze y el ahorro de batería entre Android 10 y Android 14.
El ciclo de vida del turno es la columna vertebral de la experiencia del conductor. El conductor abre la app, completa una comprobación rápida del vehículo, pulsa Conectarse y la app recorre una máquina de estados clara: conectado, en camino, en viaje, finalizando, desconectado. Cada estado se escribe en el registro inmutable de eventos de viaje del backend, que es lo que después sustenta los informes listos para auditoría para los reguladores de EE. UU. y la UE. Los pagos en efectivo y con tarjeta cierran el viaje por el mismo flujo: una pulsación para aceptar el efectivo o un recibo procesado con tarjeta que el pasajero ve al instante en su app. El mismo equipo de ingeniería lleva iOS y Android en paralelo como parte de nuestra práctica de desarrollo de apps móviles.
La consola de despacho es una aplicación de una sola página en React que tiene que mostrar cientos de vehículos en movimiento, decenas de solicitudes de viaje activas y un tablero en vivo del estado de los conductores sin que se oiga el ventilador de la CPU del operador. Se apoya en una capa de difusión por WebSockets con PostGIS como índice espacial: los conductores publican actualizaciones de posición por una conexión persistente; el backend agrupa las posiciones en teselas espaciales y envía los cambios solo a los despachadores que ven cada tesela. La consola mantiene un R-tree en el cliente para que el renderizado de miles de marcadores en el mapa basado en Leaflet sea fluido, y la interpolación de animación entre actualizaciones hace que la experiencia visual se perciba como un movimiento continuo.
El despachador es además el panel único para la intervención humana. El estado de verificación de documentos, el estado del turno, las disputas de viajes y los contadores de ingresos comparten el mismo canal que las posiciones, de modo que un despachador que ve a un conductor atascado o a un pasajero tirado puede reasignar, reembolsar o contactar en segundos. La consola se combina con nuestra práctica de cloud y DevOps para la infraestructura de WebSockets, dimensionada para absorber el perfil de carga de una flota nacional —tráfico con picos en hora punta, conmutación por error multirregión y el tipo de ventana de respuesta a incidencias en la que cada segundo de datos obsoletos cuesta dinero—. Los despachadores de varias ciudades pueden acotar su vista por región sin reconstruir la página, y así una sola consola cubre Países Bajos y la costa este de EE. UU. al mismo tiempo durante las guardias transatlánticas.
El motor de precios y el flujo de verificación de documentos soportan el peso regulatorio de la plataforma. El motor de precios es una pequeña capa específica del dominio en el backend de Laravel que toma la tarifa base, la distancia, el tiempo, la región y factores dinámicos y devuelve una vista previa transparente al pasajero antes de que pulse Reservar. La transparencia es deliberada: los reguladores de California, Texas y el Reino Unido exigen cada vez más a los operadores de VTC que divulguen su lógica de precios, y un multiplicador de tarifa dinámica opaco es un pasivo regulatorio que no queríamos incorporar. Los operadores pueden ajustar los precios regionales —tarifas base distintas para Países Bajos, Alemania o Florida— desde un único almacén de configuración sin publicar código.
El alta de conductores incorpora el permiso de conducir, la matrícula del vehículo, el seguro y una comprobación de antecedentes, y los pasa por una cola de verificación que combina controles automáticos (prueba de vida del documento, análisis de caducidad, confianza del OCR) con una fase de revisión humana. Los registros se conservan según la normativa local de movilidad y se cifran en reposo con rotación de claves; el sistema mantiene una pista de auditoría inmutable por conductor y por viaje. El enfoque está construido para alinearse con las obligaciones del RGPD para usuarios de la Unión Europea y las de la CCPA / CPRA para usuarios de California y del resto de Estados Unidos.
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ó al agregador desde los requisitos del operador hasta producción en las superficies de pasajero, conductor y despachador.
Mapeo del flujo de trabajo del operador (línea base de despacho telefónico), modelo de expansión nacional, primitivas de precios regionales y revisión de la normativa de movilidad de EE. UU. y la UE sobre registros de viajes y alta de conductores.
Esqueleto del backend con Laravel + PostGIS, diseño de la difusión por WebSockets, almacén de eventos de viaje con esquema inmutable de solo anexado, esquema del flujo KYC, abstracción de vías de pago (efectivo + tarjeta).
La app nativa de conductor en Kotlin y la consola de despacho en React se entregaron primero para sembrar la oferta; la app nativa de pasajero en Swift se entregó después; reserva con una pulsación, vista previa del precio y seguimiento en tiempo real.
KYC del conductor de principio a fin, política de retención de registros de viajes por jurisdicción, control de acceso del despachador, prueba de carga de PostGIS al tamaño de flota nacional previsto y coreografía de revisión en las tiendas.
Envío a App Store + Google Play en las tiendas de EE. UU. y la UE, despliegue de la consola de despacho por ciudad, runbooks de guardia para la capa de WebSockets y conciliación posterior al lanzamiento al final de cada turno.
Un agregador nacional de taxis es, operativamente, un problema de muchas ciudades disfrazado de un solo producto. Cada ciudad tiene su propia bolsa de conductores, su propio patrón de hora punta y —en EE. UU. y la UE— su propio perfil regulatorio. La plataforma modela cada ciudad como un tenant de primer nivel de la consola de despacho: los despachadores solo ven las ciudades que tienen asignadas, las reglas de precios regionales viven en un almacén de configuración por ciudad y la difusión por teselas PostGIS acota el tráfico de WebSockets por ciudad, de modo que la hora punta de una ciudad nunca deja sin actualizaciones al despachador de otra. La rotación de guardias funciona igual en la capa de ingeniería: el backend, la capa de WebSockets y la consola de despacho están instrumentados con Prometheus y Grafana para que un ingeniero de guardia en horario CET pueda relevar a otro que cubra el horario de la costa este de EE. UU. sin una sincronización verbal. Todo el subsistema se construyó para ampliarse con limpieza: añadir una ciudad es un cambio de configuración en el almacén de tenants y no una publicación de código, y un mercado nuevo —por ejemplo, la expansión al Reino Unido o a Irlanda— se incorpora sin reescribir la lógica de despacho.
Convenient Taxi Aggregator se diseñó para operadores de movilidad que atienden a pasajeros y conductores en Estados Unidos y la Unión Europea. La versión en inglés da servicio a usuarios de California, Nueva York, Texas, Florida y Washington en EE. UU., y 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 tienen en cuenta la región en la capa del cliente: los usuarios de la UE y del EEE reciben una pantalla de consentimiento granular al estilo del RGPD, con interruptores independientes para la retención de registros de viajes y la analítica de producto opcional; 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 europeos 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 Oregon CPA. Los flujos de alta de conductores conservan los documentos según los requisitos de la normativa local de movilidad, y los registros de viajes listos para auditoría convierten el cumplimiento regional en un ejercicio de divulgación honesta y no en un problema de segregación de datos por jurisdicción.
El despliegue del backend se ejecuta en paralelo en regiones de la UE y de EE. UU. —Países Bajos, Alemania, Francia, Suecia e Irlanda para la cobertura de la UE; el este y el oeste de EE. UU. para Norteamérica—, con instancias de PostGIS y pasarelas de WebSockets aprovisionadas de forma idéntica mediante Terraform. El servicio de asignación que elige al conductor disponible más cercano ejecuta workers sin estado fijados a regiones de EE. UU. o de la UE para futuros compromisos de residencia de datos. Tanto la clasificación por edad de App Store como la clasificación de contenido de Google Play se calibraron para una plataforma de movilidad, y la política de privacidad dentro de la app se redactó para documentar exactamente la arquitectura anterior, citando directamente las obligaciones del RGPD y las obligaciones de la CCPA de California. El equipo de ingeniería responsable del desarrollo trabaja con una jornada CET con solapamiento con la costa este de EE. UU. (9:00–13:00 ET) para las reuniones diarias, la coreografía de revisión en las tiendas y la respuesta a incidencias de los despachadores: la franja horaria que permite a un equipo de operaciones estadounidense y a un equipo de ingeniería europeo compartir cuatro horas de solapamiento en directo cada día.
La hoja de ruta activa de desarrollo de software a medida del agregador incluye un nivel de viajes corporativos para cuentas B2B en EE. UU. y la UE, una integración más profunda con procesadores de pago regionales, una app de conductor tolerante a la falta de conexión para rutas rurales de EE. UU. con poca cobertura y una capa de programación para que los pasajeros reserven viajes con antelación. Los planes de infraestructura incluyen un mayor particionado (sharding) de PostGIS para el volumen previsto de varios millones de viajes, un arnés interno de verificación continua para el almacén de eventos de viaje y una futura evaluación de preparación independiente integrada en la hoja de ruta de cloud y DevOps.
Si está planificando un agregador de VTC, una plataforma de movilidad corporativa o cualquier producto multiapp en tiempo real en el que el sistema de despacho deba resistir la revisión de un regulador para públicos de EE. UU. y la UE, hemos entregado este stack de principio a fin y podemos acortar de forma notable el calendario del desarrollo. El equipo de ingeniería responsable trabaja dentro de YuSMP Group. Trabajamos a precio cerrado para MVP bien delimitados y con equipos de desarrollo dedicados para la entrega continua, con jornada CET y una ventana 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 centrado en una app nativa de pasajero, una app nativa de conductor y una consola web de despacho, con transmisión de GPS en tiempo real, precios básicos y pagos en efectivo y con tarjeta, suele costar entre $180k y $360k. Añadir cobertura nacional, verificación de documentos con flujos KYC, precios dinámicos de tipo surge, registros de viajes listos para auditoría, vistas de despacho multiciudad e infraestructura de WebSockets con nivel de SLA lleva una plataforma de calidad de producción a $400k–$850k. Los principales factores de coste son la capa de tiempo real del despachador, el alta de conductores y el backend de transmisión de GPS ajustado para la latencia de EE. UU. y la UE.
Las apps de VTC transmiten el GPS con cadencia de un segundo, mantienen la pantalla encendida mientras se conduce y dependen de API de batería y de ubicación en segundo plano específicas de cada plataforma que maduran más rápido en nativo que en los wrappers de Flutter. Kotlin y Swift nativos exponen directamente las primitivas de servicio en primer plano y CoreLocation, de modo que la app del conductor sigue activa en Samsung, Xiaomi, OnePlus, Pixel e iPhone durante todo un turno sin cierres por parte del optimizador de batería. Flutter es excelente para apps con muchos formularios, pero paga un coste medible en la transmisión continua de la ubicación y en la revisión de App Store para justificar el permiso de ubicación en segundo plano.
Una consola de despacho en tiempo real se apoya en una capa de difusión por WebSockets con un índice espacial en el servidor. Los conductores publican actualizaciones de posición por una conexión persistente; el backend usa PostGIS para agrupar las posiciones en teselas y envía los cambios a los despachadores que ven cada tesela. La consola mantiene un R-tree en el cliente para que el renderizado de cientos de marcadores en movimiento sea fluido en un navegador. El estado de verificación de documentos, el estado del turno y los contadores de ingresos comparten el mismo canal, de modo que los despachadores ven un estado coherente e intervienen en segundos y no en minutos.
El alta de conductores incorpora el permiso de conducir, la matrícula del vehículo, el seguro y una comprobación de antecedentes, y los pasa por una cola de verificación que combina controles automáticos (prueba de vida del documento, análisis de caducidad, confianza del OCR) con una fase de revisión humana. Los registros se conservan según la normativa local de movilidad —distinta en California, en Alemania o en el Reino Unido— y se cifran en reposo con rotación de claves. El sistema mantiene una pista de auditoría inmutable por conductor para que el operador pueda responder a las preguntas de los reguladores en las jurisdicciones de EE. UU. y la UE sin tener que hacer arqueología manual.
Un despliegue por fases que siembra primero la oferta —app de conductor y consola de despacho— y luego abre la app de pasajero suele tardar entre 14 y 20 semanas para un MVP de una sola ciudad. Ampliar a cobertura nacional, verificación de documentos, precios dinámicos de tipo surge y registros de viajes listos para auditoría suma entre 8 y 14 semanas. La capa de WebSockets en tiempo real y el backend espacial con PostGIS suelen dominar el calendario porque tienen que resistir miles de posiciones de conductores simultáneas en regiones de EE. UU. y la UE antes del lanzamiento.
Casos relacionados
Marketplace de autopiezas más CRM de vendedores: búsqueda por VIN, inventario en varias ubicaciones y entrega integrada en EE. UU. y la UE.
Ver el caso →
Ecosistema offline-first que sustituye los diarios en papel para el control de procesos de reactores: tres apps coordinadas y almacén de registro de auditoría.
Ver el caso →
App de cliente, app de preparador y panel de administración para una cadena regional de supermercados, con un proceso logístico diseñado desde cero.
Ver el caso →
Apps nativas para iOS y Android y multiplataforma, con pipelines de publicación listos para las tiendas.
Más información →
Plataformas a medida diseñadas para su modelo de negocio, que escalan sin problemas desde el MVP hasta millones de usuarios.
Más información →
Plataformas SaaS multi-tenant con SSO, facturación y residencia fijada por región. SOC 2 en curso.
Más información →Cuéntenos algunos detalles y un consultor sénior le responderá en un día hábil.