Caso de éxito · Micromovilidad · Móvil e IoT
Caso de éxito de app de patinetes eléctricos compartidos: cómo creamos una plataforma completa de alquiler de patinetes eléctricos (apps nativas para clientes en iOS y Android, un plano de control de telemática IoT, geovallado y un panel de operaciones) para un operador de micromovilidad que tenía los patinetes y los permisos municipales, pero necesitaba el software. El producto atiende ya a más de 5,000 usuarios satisfechos en EE. UU. y la UE.
El cliente era un operador de micromovilidad con activos reales (una flota de patinetes eléctricos y los permisos municipales para operarlos), pero sin capacidad interna para la compleja ingeniería de telemática y móvil de la que depende realmente un negocio de patinetes compartidos. Tener el hardware es solo la mitad del negocio; la otra mitad es el software que convierte un patinete aparcado en un activo que los usuarios de Estados Unidos y la Unión Europea pueden descubrir, desbloquear, localizar y pagar. El encargo era una plataforma informática completa: apps nativas para usuarios en iOS y Android, un panel de administración para gestionar la flota, los precios y las zonas de operación y, la parte que hace o deshace un producto de micromovilidad, una capa de comunicación fiable entre la app y los controladores de los patinetes para el bloqueo, el desbloqueo y el control de velocidad en remoto. La creamos desde cero con YuSMP Group, empezando por un análisis práctico del hardware de un prototipo físico de patinete y no solo de las fichas técnicas del proveedor, y entregamos un producto que ya da servicio a más de 5,000 usuarios en App Store y Google Play.
Un resumen de lo que aportó el desarrollo de patinetes compartidos en iOS, Android y un plano de control de telemática IoT.
La decisión de arquitectura que domina un desarrollo de micromovilidad es cómo llega el teléfono del usuario al patinete. Elegimos deliberadamente un modelo de telemática con retransmisión por servidor (la app nunca da órdenes directamente al controlador) en lugar de una vía de control directo entre dispositivo y teléfono. Cuando un usuario escanea un código QR, la app envía una intención al backend; el backend autentica el viaje, comprueba el saldo del monedero y las reglas de la zona y retransmite después una orden firmada por el canal celular de telemática hasta el controlador del patinete. El controlador la confirma y solo entonces la app cambia el estado del viaje. Esta indirección es lo que hace seguro facturar sobre la plataforma: cada desbloqueo, bloqueo y acción de geovallado es un evento del servidor con pista de auditoría, y no un mensaje Bluetooth de «lanzar y olvidar» que puede suplantarse o perderse sin dejar registro. La misma disciplina del plano de control se traslada a nuestra práctica de desarrollo de software a medida en productos de movilidad.
Mapeamos el protocolo de petición y respuesta del controlador por el camino difícil: un equipo directivo multidisciplinar (un analista de negocio, un arquitecto de sistemas y un director de backend) trabajó con un prototipo físico de patinete, y no solo con la hoja de datos del controlador, y elaboró diagramas de secuencia detallados que cubren cada interacción del usuario. La comparación siguiente resume por qué ganó el modelo de retransmisión para una flota que debe satisfacer a los reguladores municipales de EE. UU. y la UE.
| Criterio | Retransmisión por servidor (este desarrollo) | Bluetooth directo | SDK de marca blanca |
|---|---|---|---|
| Pista de auditoría de órdenes | Cada acción es un evento registrado en el servidor | Solo local: difícil de conciliar con la facturación | Controlada por el proveedor, a menudo opaca |
| Alcance hasta el patinete | En cualquier lugar con cobertura celular: no hace falta proximidad | El teléfono debe estar junto al patinete | Varía según el proveedor |
| Aplicación del geovallado | El servidor envía velocidad/parada al cruzar el límite | Requiere la app en primer plano y proximidad | Incluido, pero no personalizable |
| Seguridad ante pérdida de señal | Cola de órdenes + protocolo de confirmación | Fallo silencioso: el usuario puede recibir un cobro erróneo | Depende de la implementación del SDK |
| Integridad de la facturación | Se cobra solo al confirmar el desbloqueo/bloqueo | Difícil de garantizar | Definida por el proveedor |
| Observabilidad de la flota | Panel de administración central, mapa en tiempo real | Sin vista central | Portal del proveedor: limitado |
| Personalización y propiedad | Código completo: propiedad del operador | Solo en la app | Con licencia, riesgo de dependencia |
Referencias de la plataforma: documentación de Core Location de Apple, referencia de los servicios de ubicación de Android.
El cliente de iOS está desarrollado en Swift con un flujo de una pantalla hasta el viaje: un mapa en vivo de los patinetes cercanos, un punto de entrada para escanear el QR y una tarjeta de detalle del patinete que muestra la batería, la autonomía estimada, la tarifa de inicio y el precio por minuto antes de que el usuario se comprometa. La capa de mapa usa Core Location de Apple para la posición del usuario y recibe en streaming las posiciones GPS de los patinetes desde el backend, de modo que el selector refleja la flota real sin bloquearse esperando a una red lenta. El camino de desbloqueo por QR es donde la mayoría de los usuarios se forman su primera impresión del producto, y donde dedicamos un esfuerzo de ingeniería desproporcionado: escanear, validar la elegibilidad del monedero y de la zona, enviar la intención de desbloqueo y mostrar un estado claro de viaje iniciado en cuanto el controlador lo confirma.
Como la confirmación del controlador puede retrasarse con una cobertura celular débil, el flujo de iOS se construye en torno a estados de viaje explícitos (inactivo, desbloqueando, viaje iniciado, finalizando) y no a una interfaz optimista que finge que el patinete se desbloqueó antes de confirmarlo. Un usuario nunca pasa a un viaje facturable hasta que el backend tiene un desbloqueo confirmado por el controlador, que es la propiedad de corrección más importante en una app de patinetes. La superficie completa de iOS se entrega como parte de nuestra práctica de desarrollo de aplicaciones móviles.
El cliente de Android está escrito en Kotlin y ejecuta el viaje activo dentro de un servicio en primer plano. El servicio en primer plano es obligatorio: en las familias de dispositivos Samsung, Xiaomi, OnePlus y Pixel, los optimizadores de batería agresivos terminan en pocos minutos los procesos que solo se ejecutan en segundo plano, y un viaje en patinete no puede permitirse perder a mitad de camino la conexión con la lógica de medición del trayecto y de geovallado. El servicio mantiene viva la sesión del viaje, envía en streaming la posición GPS del usuario al backend para el seguimiento de la flota y las comprobaciones de geovallado, y actualiza en pantalla la distancia en vivo, el tiempo transcurrido y el precio acumulado, además de ofrecer un control de bloqueo durante el viaje.
La lógica de geovallado es el corazón regulatorio de la plataforma. A medida que el usuario se mueve, el backend compara la posición GPS del patinete con los polígonos de las zonas de operación configurados en el panel de administración. Entrar en una zona lenta envía una orden de límite de velocidad al controlador; cruzar un límite estricto detiene el patinete; llegar a una zona de aparcamiento habilita el fin del viaje. Esta aplicación en el servidor es lo que permite a una ciudad de EE. UU. o de la UE aprobar la flota, y funciona sobre el mismo plano de control que gestiona la referencia de envío de ubicación descrita en servicios de ubicación de Android. El mismo equipo de ingeniería se ocupa de iOS y Android en paralelo dentro de nuestra práctica de ingeniería para iOS y Android.
El monedero dentro de la app permite al usuario cargar saldo por adelantado y fijar un límite de gasto, de modo que un único estado de pago de tipo suscripción se resuelve limpiamente entre viajes sin volver a autorizar una tarjeta en cada trayecto. Por debajo está el plano de control de telemática: un backend que guarda el mapa de la flota, los polígonos de las zonas de operación, la cola de órdenes por patinete y el libro de facturación. La cola de órdenes es la capa a prueba de fallos: si se envía una orden de bloqueo o desbloqueo y el controlador no la confirma (cobertura celular caída, batería agotada, reinicio del controlador), la cola reintenta con retroceso y concilia el estado del viaje para que un usuario nunca pague por un patinete que en realidad no respondió. Los identificadores están muy acotados: el flujo de ubicación del usuario alimenta las comprobaciones de geovallado y el seguimiento de la flota, y se conserva como historial de viajes con consentimiento explícito y según la región, y no se explota como un perfil de seguimiento continuo.
El tratamiento de datos está diseñado para alinearse con las obligaciones del RGPD para los usuarios de la Unión Europea y con las obligaciones de la CCPA / CPRA para los usuarios de California y del resto de Estados Unidos: los datos de ubicación se recogen con la finalidad operativa del viaje y del geovallado, se comunican con claridad y no se reutilizan para otros fines. La consola de operaciones de la flota, desarrollada con React, ofrece al personal un mapa en tiempo real, un editor de zonas, controles de precios y el estado de la telemática de cada patinete.
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ó la plataforma desde un prototipo físico de patinete hasta producción en iOS, Android y un plano de control de telemática IoT.
Análisis práctico de un prototipo físico de patinete, mapa del protocolo de petición y respuesta del controlador, diagramas de secuencia de las interacciones del usuario, requisitos de permisos municipales y de geovallado de EE. UU. + UE y mapa del enfoque del RGPD + la CCPA.
Esqueleto del backend en Laravel, modelo de órdenes con retransmisión por servidor, cola de órdenes a prueba de fallos con confirmación y retroceso, mapa de la flota, modelo de polígonos de zonas de operación y libro de facturación.
App de cliente en Swift para iOS y app de cliente en Kotlin para Android: mapa GPS en vivo, desbloqueo por QR, estados del viaje, medición del trayecto con servicio en primer plano, monedero dentro de la app y límite de gasto.
Aplicación del geovallado con limitación automática de velocidad y zonas de parada, QA de seguridad ante pérdida de señal y batería baja, pruebas de integridad de la facturación y panel de operaciones de administración en React.
Envío a App Store y Google Play en las tiendas de EE. UU. y la UE, despliegue de la flota, observabilidad de la flota en tiempo real y telemetría a nivel de viaje que alimenta el ajuste de precios y zonas.
Un negocio de patinetes compartidos vive o muere por su consola de operaciones, así que el panel de administración en React se trató como un entregable de primer nivel y no como un añadido de última hora. El personal dispone de un mapa en tiempo real de cada patinete con su nivel de batería, su estado de bloqueo y el estado de su telemática, y puede enviar operaciones de campo para cambios de batería bajos o reubicaciones. Los precios son totalmente configurables (tarifa de inicio, tarifa por minuto y ajustes por franja horaria o zona) sin una publicación de código, porque los precios de la micromovilidad se ajustan constantemente a la demanda y a los acuerdos con las ciudades. El editor de zonas es la herramienta regulatoria: el personal dibuja y edita zonas de prohibición, zonas lentas y áreas de aparcamiento como polígonos en el mapa, y esos polígonos pasan directamente al motor de geovallado que los aplica a los patinetes en tiempo real. Como las zonas de operación, los precios y el inventario de la flota residen tras el mismo plano de control, un operador puede incorporar una nueva ciudad de EE. UU. o de la UE como un ejercicio de configuración (nuevos polígonos, nuevos precios, nuevos parámetros de permisos) y no como una bifurcación del código, que es exactamente la palanca que debe dar una plataforma de software a un negocio de hardware.
La plataforma se lanzó en Apple App Store y Google Play con fichas activas en Estados Unidos y en la Unión Europea, y atiende ya a más de 5,000 usuarios con una única versión en inglés por plataforma. La micromovilidad es una de las categorías de software más reguladas a nivel local, por lo que la arquitectura traslada las normas específicas de cada ciudad a la configuración: cada zona de operación, límite de velocidad y restricción de aparcamiento es un dato del panel de administración, no una base de código por ciudad. Los flujos de consentimiento dependen de 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 que cubre el tratamiento de la ubicación durante el viaje, y 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 normas 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, con los datos de ubicación del viaje acotados a la finalidad operativa del trayecto y del geovallado.
En el lado europeo, la plataforma está estructurada para admitir el despliegue en ciudades de Países Bajos, Alemania, Francia, Suecia e Irlanda, donde los permisos de patinetes compartidos dependen de un geovallado y un control de velocidad demostrables, exactamente la capacidad en torno a la cual se construyó el plano de control. El equipo de ingeniería que está detrás 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 coordinación de las revisiones de las tiendas y la respuesta a incidencias, la franja horaria que permite a un equipo de producto orientado a EE. UU. y a un equipo de ingeniería europeo compartir cuatro horas de solapamiento en directo cada día. Tanto la clasificación por edades de App Store como la clasificación de contenido de Google Play se calibraron para una app de transporte que gestiona ubicación en vivo.
La hoja de ruta activa de desarrollo de software a medida incluye precios dinámicos basados en la demanda, una comprobación de daños y fotos al terminar el viaje, un nivel de recompensas para los usuarios y una analítica más profunda del estado de la flota que señale los patinetes que tienden al mantenimiento antes de que fallen en la calle. Los planes de infraestructura incluyen más automatización del pipeline de órdenes de telemática y un plano de control reforzado y observable integrado en la hoja de ruta de cloud y DevOps, para que el operador pueda añadir ciudades de EE. UU. y la UE sin rediseñar la arquitectura. La plataforma atiende al ámbito más amplio de la logística y la movilidad, donde los mismos patrones de seguimiento por GPS y control IoT se repiten en vehículos compartidos y flotas de última milla.
Si está planificando un producto de patinetes eléctricos o de movilidad compartida en el que el software deba convertir una flota de hardware en un servicio facturable y favorable a los reguladores para públicos de EE. UU. y la UE, hemos entregado este stack de principio a fin (apps para usuarios, plano de control de telemática, geovallado y panel de operaciones) y podemos acortar de forma significativa el plazo de desarrollo. El caso está documentado en yusmpgroup.ru, y el equipo de ingeniería que lo desarrolló forma parte de YuSMP Group. Trabajamos a precio cerrado para MVP bien acotados y con equipos de desarrollo dedicados para la entrega continua, con una 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 micromovilidad con apps para usuarios en iOS y Android, un mapa GPS de patinetes, desbloqueo por QR, medición del trayecto y un panel de administración básico suele costar $140k–$280k. Añadir un plano de control de telemática IoT completo, geovallado con limitación automática de velocidad, gestión de bloqueos a prueba de fallos, un monedero dentro de la app y precios dinámicos lleva una plataforma completa a $320k–$700k. Los principales factores de coste son la capa de comunicación con los controladores de los patinetes, el motor de geovallado y el panel de operaciones para la gestión de la flota, los precios y las zonas.
La app del usuario nunca habla directamente con el patinete. Un escaneo de QR o un toque envía una intención al backend, que retransmite una orden firmada de bloqueo o desbloqueo por el canal de telemática hasta el controlador del patinete. El controlador la confirma y la app actualiza el estado del viaje. Lo difícil es el camino a prueba de fallos: la cola de órdenes debe gestionar la pérdida de señal celular, la batería baja y las confirmaciones parciales para que un usuario nunca pague por un patinete que en realidad no se desbloqueó.
El geovallado define límites virtuales en el mapa: zonas de prohibición, zonas lentas y áreas de aparcamiento. Cuando la posición GPS de un patinete cruza un límite, la plataforma envía al controlador una orden para reducir la velocidad o detenerse. Es un requisito esencial de seguridad urbana y de regulación: la mayoría de las ciudades de EE. UU. y la UE autorizan los patinetes compartidos con la condición de que los operadores puedan hacer cumplir los límites de velocidad y mantener los patinetes fuera de las zonas peatonales, así que el motor de geovallado no es opcional: es el permiso.
Un MVP acotado con un mapa GPS de patinetes, desbloqueo por QR, medición del trayecto, un monedero dentro de la app y el envío a ambas tiendas suele llevar de 16 a 22 semanas. Añadir el plano de control de telemática IoT completo, el geovallado con limitación automática de velocidad, la gestión de bloqueos a prueba de fallos y el panel de operaciones suma de 8 a 12 semanas. El descubrimiento de la integración de hardware (trabajar con un prototipo físico de patinete para mapear el protocolo de petición y respuesta del controlador) suele subestimarse y debe presupuestarse como una fase propia.
Tener el hardware y los permisos municipales es una mitad del negocio; la otra mitad es el software que convierte un patinete aparcado en un activo alquilable, localizable y facturable. La telemática compleja, el seguimiento de la flota por GPS, el geovallado y un monedero de viajes de nivel de pagos son ámbitos de ingeniería especializados. Un equipo que ha entregado este stack para iOS y Android puede mapear el protocolo del controlador a partir de un prototipo físico, construir la capa de órdenes a prueba de fallos y poner en marcha la plataforma de administración mucho más rápido que desarrollar esa capacidad internamente desde cero.
Casos relacionados
Plataforma de reservas nativa para iOS + Android con disponibilidad en vivo y descubrimiento geolocalizado en EE. UU. y la UE.
Ver el caso →
Plataforma móvil de consumo con mapas, servicios basados en la ubicación y un desarrollo multilingüe para usuarios internacionales.
Ver el caso →
Marketplace de alquiler con flujo de reservas, pagos y un back office de operaciones 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 →
Planos de control reforzados y observables e infraestructura Terraform que escalan por las regiones de EE. UU. y la UE.
Explorar cloud y DevOps →Cuéntenos algunos detalles y un consultor sénior le responderá en un día hábil.