Caso de éxito · Logística · Última milla · Móvil
Caso de éxito de xRouten: cómo tomamos una app Android heredada críticamente inestable —en producción con un operador logístico alemán y que perdía ingresos por entregas fallidas—, la estabilizamos, refactorizamos su núcleo de rutas y después entregamos una app iOS equivalente lista para publicar. Optimización de rutas multipunto, seguimiento de conductores en tiempo real, facturación y pagos dentro de la app, entregado para flotas en producción en Alemania y listo para escalar en toda la Unión Europea y en Estados Unidos.
xRouten es un producto de navegación y planificación de rutas para flotas empresariales, creado y operado desde Alemania. Cuando el cliente contrató a YuSMP, la app Android existente estaba en producción con operadores logísticos de pago, pero adolecía de bajo rendimiento, errores frecuentes y fallos críticos que alteraban directamente las operaciones: entregas fallidas, ventanas de recogida incumplidas y pérdidas económicas reales para los clientes finales del operador. El equipo de producto necesitaba dos cosas en un único proyecto: primero, una intervención de estabilización de emergencia en la app Android en producción para frenar la fuga de usuarios y recuperar la confianza; segundo, una app iOS equivalente con paridad total de funciones para que el operador pudiera ampliar su flota de conductores a iPhone. Asumimos ambas: la refactorización del código heredado e inestable de Android en Kotlin, seguida de un desarrollo desde cero de iOS en Swift sobre el mismo backend, y entregamos un producto listo para publicar tanto en Google Play como en la App Store de Apple, en producción con un operador logístico alemán y listo para escalar a los mercados más amplios de la Unión Europea y Estados Unidos.
Un resumen de lo que aportó el proyecto xRouten en la refactorización de Android y el nuevo desarrollo de iOS.
La superficie más crítica para el negocio en xRouten es el constructor de rutas. Un despachador o un conductor introduce en la app una lista de paradas —a veces unas pocas, a menudo decenas— y la app debe devolver una secuencia optimizada en un tiempo tan corto que parezca instantáneo. En la versión heredada, este cálculo era poco fiable: las rutas no se calculaban, agotaban el tiempo de espera o devolvían secuencias claramente subóptimas que hacían perder horas de conductor y consumían combustible. Reescribimos el núcleo de rutas sobre la API de matriz de un SDK de mapas: el cliente envía la lista de paradas a un optimizador en el servidor que obtiene la distancia y el tiempo estimado de llegada entre pares, ejecuta una heurística 2-opt sobre la matriz resultante y devuelve una secuencia de paradas casi óptima con indicaciones paso a paso para cada tramo.
El cliente móvil dibuja la ruta, admite la reoptimización incremental cuando se añaden paradas a mitad de turno o se marcan como completadas, y guarda en caché la matriz de cada ruta para que una sola entrega completada no desencadene un recálculo completo. El resultado es un constructor de rutas que devuelve al instante el cálculo de los caminos óptimos entre decenas de paradas, exactamente el comportamiento de cara al usuario que el cliente había pedido desde el principio de la relación. La misma arquitectura se reutiliza en el desarrollo de iOS sin cambios en el backend: el optimizador es independiente de la plataforma y los clientes móviles son capas de presentación finas sobre un stack compartido de desarrollo de software a medida.
| Criterio | Versión heredada (antes del proyecto) | Versión refactorizada (después del proyecto) |
|---|---|---|
| Cálculo de rutas multipunto | Tiempos de espera agotados y secuencias claramente subóptimas | Cálculo instantáneo con una API de matriz + solver 2-opt |
| Seguimiento de la ubicación del conductor | Actualizaciones esporádicas, marcadores del mapa que saltan | Transmisión fluida en tiempo real con muestreo adaptativo |
| Factura y pago | Solución alternativa fuera de la app: los conductores usaban herramientas externas | Generación de facturas dentro de la app + sistema de pagos operativo |
| Errores críticos en producción | Varios: provocaban entregas fallidas y pérdida de ingresos | Eliminados en la refactorización |
| Interfaz y percepción de marca | Anticuada; quejas de usuarios visibles en las reseñas de las tiendas | Interfaz moderna rediseñada que mejora la UX |
| Disponibilidad en iOS | Ninguna: solo Android | Versión en Swift lista para publicar con paridad de funciones |
Referencias de la plataforma: Kotlin, Swift, Servicios en primer plano de Android, Apple CoreLocation.
La segunda función central era la transmisión fiable de la ubicación en tiempo real de los conductores del operador, mostrada con fluidez en el mapa del despachador sin los saltos y huecos que afectaban a la versión heredada. En Android nos apoyamos en un servicio en primer plano en Kotlin para mantener vivo el muestreo del GPS a través del modo Doze y de los agresivos optimizadores de batería que incorporan las familias de dispositivos Samsung, Xiaomi, OnePlus y Pixel; sin él, las actualizaciones de ubicación mueren a los pocos minutos de apagarse la pantalla. En iOS, la superficie equivalente usa CoreLocation con la autorización de ubicación en segundo plano adecuada, junto con la monitorización de cambios significativos como alternativa de bajo consumo.
El muestreo es adaptativo: a baja velocidad en el tráfico denso de la ciudad, las coordenadas del conductor se actualizan cada cinco a diez segundos; en la autopista entre ciudades alemanas la frecuencia de muestreo se espacia, porque el despachador no necesita una precisión de 1 Hz cuando un vehículo avanza en línea recta a 120 km/h. La vista del despachador interpola entre muestras para que el marcador se deslice en lugar de saltar, lo que hace que una frecuencia de muestreo baja resulte fluida para el operador. Las actualizaciones de ubicación se transmiten por un WebSocket persistente —la misma elección de transporte que usamos para el chat en nuestro trabajo de desarrollo de apps móviles de consumo—, de modo que un breve corte de conectividad (traspaso de antena entre LTE y 5G, habitual en las rutas alemanas de larga distancia) se recupera en menos de dos segundos sin perder la última posición conocida.
El tercer pilar de la refactorización fue un módulo de documentación digital: en el punto de entrega, el conductor genera una factura para el cliente directamente desde la app, la envía desde la misma pantalla y cobra sin salir del flujo de trabajo. En el producto heredado, los conductores improvisaban para cubrir este vacío con papel o con apps ajenas, una pista documental que incumplía las expectativas de cumplimiento alemanas y ralentizaba cada entrega. El nuevo módulo genera una factura estructurada (PDF para el cliente, datos estructurados para el back office del operador), adjunta la prueba de entrega y encamina el pago a través de una pasarela de pago integrada —no mediante la compra dentro de la app de App Store, que Apple excluye expresamente para bienes y servicios físicos—.
La fiabilidad procede de un commit en dos fases (two-phase commit) entre la emisión de la factura y la intención de pago: una caída de red en campo no puede dar lugar a un cargo sin la factura correspondiente ni a una factura sin un resultado de pago registrado. El flujo admite una captura correcta, una captura diferida (el conductor está en un sótano sin conexión y la factura queda en cola para sincronizar en la siguiente conexión) y un fallo definitivo (tarjeta rechazada: el conductor ve un error en pantalla y puede aceptar otro medio de pago en la misma pantalla). El resultado es el sistema de pagos operativo que el cliente había pedido desde el principio, con una fiabilidad de las transacciones equiparable a la que los clientes del operador esperan de cualquier servicio alemán moderno de última milla.
Enfoque de cumplimiento: alineado con el RGPD · preparado para ISO 27001 · SOC 2 Type II en curso · apto para HIPAA · CCPA contemplada.
Tres características del proyecto hicieron de xRouten un encargo nada trivial y marcaron cómo llevamos el trabajo. Primero, la base de código era un producto heredado con una superficie existente inestable: no partíamos de cero en un espacio vacío, estábamos estabilizando un sistema en marcha del que dependían conductores reales. Eso significaba que cada cambio tenía que ser defendible ante la base de usuarios existente: refactorizar por capas, proteger las nuevas rutas de código con feature flags y publicar versiones intermedias que fueran retirando de forma incremental las peores clases de errores, en lugar de una reescritura de golpe que habría dejado a los operadores semanas con una versión rota.
Segundo, lo que había en juego era alto de un modo que rara vez ocurre en las apps de consumo: un error de la app no producía una mala experiencia de usuario, sino una entrega fallida y una pérdida económica real para el cliente final del operador. Esa asimetría nos llevó a una ingeniería defensiva: estados de error explícitos mostrados al conductor, reintentos con espera exponencial en cualquier operación de red que modificara el estado y comportamiento offline-first en las superficies de campo, para que un corte de conectividad nunca perdiera trabajo en silencio.
Tercero, había barreras de idioma y geográficas: toda la interfaz del producto y su documentación están en alemán, y validar la capa de rutas exigía probar con mapas alemanes y convenciones de direcciones alemanas desde un equipo de ingeniería con sede en Rusia. Lo tratamos como una disciplina de ingeniería y no como un problema: revisión por hablantes de alemán de cada cadena de la interfaz, datos de prueba de direcciones alemanas en la batería de pruebas de rutas y una matriz de QA que ejercitaba la app con patrones reales de recogida de Deutsche Post y DHL y no con datos de prueba sintéticos. Es la misma disciplina que aplicamos cuando llevamos un equipo de desarrollo dedicado para cualquier cliente de EE. UU. o de la UE cuyo mercado de operación no sea la primera lengua del equipo de ingeniería.
Un proyecto en cinco fases que llevó a xRouten desde un producto Android en producción e inestable hasta un par de apps de iOS y Android listas para publicar.
Auditoría del código Android heredado, inventario de errores críticos, priorización por impacto en el negocio (primero las entregas fallidas) y publicación de hotfixes para frenar la fuga de usuarios mientras se define el alcance de la refactorización más profunda.
Reescritura en Kotlin del constructor de rutas multipunto sobre la API de matriz de un SDK de mapas con una heurística 2-opt, batería de regresión con datos de prueba de direcciones alemanas reales y despliegue incremental protegido por un feature flag.
Transmisión de ubicación en tiempo real basada en un servicio en primer plano, interpolación fluida en el lado del despachador, generador de facturas dentro de la app e integración con la pasarela de pago con semántica de commit en dos fases.
Interfaz moderna rediseñada aplicada a ambas plataformas, cliente iOS en Swift desarrollado sobre el mismo backend con paridad de funciones en rutas, seguimiento, facturación y pagos.
Publicación en producción en Google Play de la app Android refactorizada, versión de iOS lista para publicar para su envío a App Store, fase de QA en alemán, y traspaso del runbook y de las guardias al cliente.
Al final del proyecto, el producto xRouten había pasado de ser una app Android inestable que generaba escalados de soporte a una versión lista para producción tanto en App Store como en Google Play. Los errores críticos que provocaban entregas fallidas en la versión heredada se eliminaron; la interfaz moderna rediseñada mejoró tanto la experiencia de usuario como la percepción de marca entre los conductores y los clientes del operador; el sistema de pagos dentro de la app ofreció una fiabilidad de las transacciones que la versión anterior sencillamente no tenía; y la arquitectura refactorizada está estructurada para que el equipo de producto del operador pueda añadir nuevas funciones —métodos de pago adicionales, analítica a nivel de flota, soporte multi-tenant para subcontratistas— sin heredar la deuda técnica de la versión original. El mismo backend compartido da servicio tanto a la refactorización de Android como al nuevo desarrollo de iOS, de modo que una única hoja de ruta de producto guía ambas plataformas a partir de ahora.
xRouten está en producción con un operador alemán de logística de última milla y se construyó con el mismo enfoque de ingeniería que aplicamos en nuestro trabajo para clientes de Estados Unidos y la Unión Europea. Hoy la app está pensada primero para Alemania —interfaz en alemán, documentación en alemán, validada con direcciones, redes viarias y patrones de entrega alemanes—, pero la arquitectura es independiente de la región. La abstracción del SDK de mapas admite redes de calles y formatos de dirección de EE. UU. sin cambios de código, la integración con la pasarela de pago puede cambiar de procesador regional según el mercado, y los stacks de servicio en primer plano y CoreLocation se comportan igual en dispositivos emitidos en EE. UU. y en la UE.
El enfoque de privacidad refleja el del resto de nuestro portafolio: la app está alineada con el RGPD para los usuarios europeos —relevante de inmediato en Alemania, Francia, Países Bajos, Irlanda y Suecia— y preparada para cumplir el mosaico de leyes estatales de privacidad de EE. UU.: CCPA / CPRA en California, VCDPA en Virginia, CPA en Colorado, CTDPA en Connecticut, UCPA en Utah, TDPSA en Texas y Oregon CPA. Los datos de ubicación de los conductores son la superficie más sensible de una app de logística —son, por definición, datos de vigilancia de empleados— y la arquitectura separa los flujos de ubicación de la identidad en la capa de almacenamiento, con plazos de retención configurables por operador para ajustarse a las expectativas de los comités de empresa alemanes que rigen esta categoría de datos en la UE.
La hoja de ruta de xRouten amplía la base refactorizada en direcciones que el operador no podía abordar con seguridad sobre la versión heredada: analítica a nivel de flota (productividad de los conductores, coste de ruta por entrega, desviación de combustible y tiempo frente al plan optimizado), soporte multi-tenant para que los mensajeros subcontratados puedan gestionar sus propios grupos de conductores dentro de la cuenta del operador, métodos de pago regionales adicionales (domiciliación SEPA, Klarna, Apple Pay y Google Pay) y una consola web para el despachador que replique el modelo de datos de la app móvil. Los planes de infraestructura incluyen un SLO más estricto para el optimizador de rutas (respuesta en menos de un segundo para rutas de hasta 50 paradas) y compromisos de residencia de datos en la UE respaldados por particiones de base de datos fijadas por región para ajustarse a las expectativas de privacidad del operador alemán en virtud del RGPD.
Una fase de estabilización de una app Android heredada —eliminar errores críticos, refactorizar el núcleo de rutas y publicar una versión lista para producción— suele costar entre $80k y $180k según el tamaño del código y la cobertura de pruebas. Desarrollar una versión equivalente para iOS con paridad de funciones (rutas multipunto, seguimiento en tiempo real, facturación, pagos) sobre un backend compartido suele añadir entre $120k y $250k. Los factores de coste incluyen la elección del SDK de mapas, las integraciones con pasarelas de pago y el esfuerzo de QA necesario para validar la optimización de rutas con direcciones y datos de tráfico alemanes reales.
La optimización de rutas multipunto en móvil es una variante del problema del viajante. Para flotas empresariales con decenas de paradas por ruta, el cálculo se ejecuta en el servidor contra la API de matriz de un proveedor de mapas (distancia y tiempo estimado de llegada entre cada par de paradas), con un solver heurístico —normalmente una variante de 2-opt o de Lin–Kernighan— que encuentra una secuencia casi óptima en milisegundos. El cliente móvil muestra el resultado y gestiona la reoptimización incremental cuando se añaden, quitan o completan paradas en campo. Guardar en caché la matriz de cada ruta y volver a consultar solo los pares modificados mantiene bajos los tiempos de respuesta incluso a medida que los conductores avanzan en las entregas.
El seguimiento de conductores en tiempo real en producción tiene tres piezas móviles: un servicio en primer plano en Android (y una autorización de ubicación en segundo plano en iOS) que mantiene vivo el muestreo del GPS a pesar de la suspensión del dispositivo y de los optimizadores de batería; una capa de transporte —WebSocket o MQTT— que transmite las actualizaciones de ubicación a un backend con latencia inferior a un segundo; y una vista del despachador que interpola entre muestras para mostrar un movimiento fluido en un mapa sin saltos. La batería es la restricción dominante: muestrear a 1 Hz agota rápido un teléfono, así que un desarrollo real muestrea de forma adaptativa a intervalos de 5–30 segundos según la velocidad y la geometría de la ruta.
La facturación dentro de la app en un flujo de logística genera un documento de factura estructurado (PDF o datos conformes con el estilo alemán XRechnung) en el punto de entrega, adjunta la firma del conductor y la prueba de entrega y lo envía al cliente por correo electrónico o mediante un enlace dentro de la app. El pago suele gestionarlo una pasarela de pago independiente (Stripe, Adyen o un procesador del mercado alemán) y no la compra dentro de la app de App Store, porque lo que se paga son entregas físicas y no contenido digital: las normas de compra dentro de la app de App Store excluyen expresamente esta categoría. La fiabilidad procede de un commit en dos fases (two-phase commit) entre la emisión de la factura y la intención de pago, de modo que una caída de red en campo no pueda crear un cargo sin el registro de factura correspondiente.
Una fase de estabilización de una app Android heredada —auditoría de errores críticos, refactorización del núcleo de rutas y publicación de una versión corregida en Google Play— suele tardar entre 10 y 16 semanas para una app del tamaño de xRouten. Desarrollar la versión equivalente para iOS con paridad total de funciones, incluidos los flujos de facturación y pago, suma entre 14 y 20 semanas. Los principales riesgos de calendario son la alineación de licencias del SDK de mapas, el QA para el mercado alemán (probar rutas con patrones reales de recogida de Deutsche Post y DHL) y los ciclos de revisión de App Store / Google Play cuando una app antes inestable vuelve a la tienda con permisos sustancialmente modificados.
Si opera un producto de logística de última milla o de flotas —en cualquier lugar de Estados Unidos, la Unión Europea o en un mercado como Alemania, donde importan el cumplimiento y los matices del idioma— y está sopesando una refactorización heredada, una extensión a iOS o Android o un desarrollo nuevo, hemos entregado este stack de principio a fin para un operador alemán en producción y podemos acortar de forma notable el calendario del desarrollo. El equipo de ingeniería responsable de xRouten trabaja dentro de YuSMP Group. Trabajamos a precio cerrado para refactorizaciones bien delimitadas 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.
Enfoque de cumplimiento: alineado con el RGPD · preparado para ISO 27001 · SOC 2 Type II en curso · apto para HIPAA · CCPA contemplada.
Servicios relacionados
Apps para iOS, Android y multiplataforma, del concepto a la App Store, con un nivel de calidad a la altura de la App Store.
Explorar el desarrollo de aplicaciones móviles →
Migraciones a AWS, Azure y GCP, plataformas Kubernetes, CI/CD y observabilidad para equipos de EE. UU. y la UE.
Explorar cloud y DevOps →
Ingeniería de producto de principio a fin para empresas ambiciosas de EE. UU. y la UE, a cargo de equipos sénior con prácticas alineadas con el RGPD y orientadas a SOC 2.
Explorar el desarrollo de software a medida →Casos relacionados
Plataforma social nativa para iOS + Android con descubrimiento por geo-radar, chat en tiempo real y una economía de monedas virtuales: App Store + Google Play, EE. UU. y la UE.
Ver el caso →
Plataforma web para concesionarios con sincronización con Bitrix24 CRM, autorrelleno con Dadata y alertas de voz en tiempo real: un único canal de entrada para cada solicitud de financiación de vehículos.
Ver el caso →
VPN nativa para iOS + Android con WireGuard, backend sin registros, split tunneling y lanzamiento en App Store + Google Play para EE. UU. y la UE.
Ver el caso →
Plataformas empresariales con la arquitectura como punto de partida, cumplimiento listo para auditoría e integración con SAP, Salesforce, Workday y Okta.
Más información →
Migración «strangler fig» de stacks heredados (.NET Framework, Java 8, monolito) sin el riesgo de reemplazarlo todo de golpe.
Más información →Plataformas en AWS, Azure y GCP con IaC, observabilidad y despliegues sin tiempo de inactividad.
Más información →Cuéntenos algunos detalles y un consultor sénior le responderá en un día hábil.