Plataforma operativa para un negocio de movilidad
Discovery de scope, arquitectura multi-rol y mocks gated para un operador regional de movilidad que necesitaba unificar operaciones de flota, contratos B2B y ticketing B2C en una sola plataforma.
- PWA (Next.js 16 propuesto)
- Supabase (Postgres, Realtime, RLS)
- Multi-tenant desde día uno
- Mobile-first en tres roles
De un vistazo
Un operador regional de movilidad quería una plataforma para correr su negocio: rastrear la flota, manejar contratos corporativos, vender tickets al consumidor y darle a los conductores una herramienta de trabajo que no requiriera seis apps. Lo que empezó como una conversación sobre “una app para nuestros conductores” se convirtió en un producto de tres lados después de mapear la operación real.
Lideré el scoping post-discovery que expandió el brief honestamente (con el acuerdo del cliente), produje mocks gated en tres roles, y propuse una arquitectura que shippea por fases sin comprometer al operador con los tres lados desde el día uno.
Este trabajo está en etapa de propuesta activa. Los mocks están gated a un mínimo de Tier 1; el Tier 2 desbloquea una vez que una reunión confirme budget y timeline.
El contexto
El operador corre un negocio regional de movilidad con tres grupos de usuarios a los que sirve simultáneamente:
- Operaciones internas. Una flota de vehículos, conductores en turnos rotativos, decisiones de despacho tomadas por teléfono y pizarra, y un líder de finanzas que necesita reconciliar ingresos entre los streams B2B y B2C.
- Clientes B2B. Empresas que contratan al operador para transporte de empleados, con su propia plantilla, horarios y cadencia de facturación. Estos contratos representan la parte predecible y de alto margen del negocio.
- Pasajeros B2C. Individuos que compran tickets por viaje. Menor valor por transacción, mayor volumen, y una superficie completamente distinta (booking público, pagos, push notifications).
Antes del discovery, el operador describió lo que quería como “una app para nuestros conductores, principalmente.” Después de mapear los flujos reales, la app del conductor es una de tres superficies, y no la que tiene el mayor leverage.
Discovery
El input inicial fue un audio resumen de una conversación previa. Lo transcribí y analicé, luego corrí una sesión estructurada con el operador para validar el panorama e identificar gaps. Tres hallazgos definieron el scope eventual:
El dispatcher es el cuello de botella, no el conductor. Los conductores pueden hacer su trabajo con lo que tienen. Los dispatchers no. La superficie individual más valiosa es la del dispatcher: una vista en tiempo real de dónde está cada vehículo, en qué viaje está, quiénes son los próximos pasajeros, y a qué contrato corporativo o ticket B2C corresponde cada asiento.
B2B y B2C no son el mismo producto. El lado B2B es basado en contrato: horarios predecibles, facturación por invoice, identidades de empleados atadas a la empresa cliente. El lado B2C es basado en transacción: booking público, pago inmediato, pasajeros anónimos hasta-que-pagan. Construirlos como una sola funcionalidad haría ambos peores. Construirlos como dos superficies escopeadas independientemente, compartiendo la misma flota y dispatcher, hizo la arquitectura honesta.
La decisión técnica fue más grande de lo esperado. El operador asumía inicialmente una funcionalidad simple de “tracking GPS.” Después del discovery, la pregunta era: ¿PWA por ahora, o invertir en hardware (tablets dedicadas por vehículo, módulos GPS)? Cada camino tiene cost, complejidad y timing de unlock distintos. Acordamos diferir la decisión de hardware y shippear el camino PWA primero, validando el patrón operativo antes de comprometer capital en dispositivos.
Arquitectura
El sistema propuesto es una PWA multi-tenant en Next.js 16 con Supabase para data, auth y realtime. Multi-tenant desde día uno (un operador ahora, espacio para más después sin reescribir).
Tres superficies por rol, un solo codebase. Las apps de dispatcher, conductor y pasajero son rutas dentro de la misma aplicación Next.js, gated por rol autenticado. Los componentes compartidos viven en un design system. Las superficies específicas de rol se mantienen lean (los conductores no necesitan ver el board completo del dispatcher; los pasajeros no necesitan saber que hay un dispatcher).
Realtime donde se gana su lugar. Posiciones de vehículos, vista del dispatcher de viajes activos, y actualizaciones de asignación al conductor usan Supabase Realtime. Data de menor frecuencia (términos de contrato B2B, reconciliación financiera) vive en server actions estándar. Realtime es un presupuesto; se gasta donde el operador realmente necesita updates sub-segundo y no en otro lado.
B2B y B2C separados por modelo de datos, unificados por la flota. Contratos corporativos y tickets de consumidor son tablas distintas con ciclos de vida distintos. Comparten una tabla trips donde sucede el movimiento real; cada trip carga identificadores de contrato o de ticket, nunca ambos. El dispatcher ve la vista unificada; la lógica de billing ve los streams separados.
PWA primero, hardware después. La Fase 1 shippea como PWA en los tres roles, instalada en los teléfonos que los conductores ya cargan y en el desktop del dispatcher. Si el volumen operativo y el budget lo justifican, la Fase 2 considera tablets dedicadas en vehículo y módulos GPS. La PWA no bloquea el camino de hardware; lo des-arriesga.
Dirección de diseño
Los mocks gated se produjeron bajo disciplina deliberada de scope. Mock Tier 1 cubre las superficies que tienen que verse bien para que la propuesta aterrice: dispatcher home, asignación al conductor, flow de booking del pasajero. Mock Tier 2 (manejo de contratos, reconciliación financiera, admin) solo shippea si la conversación de budget lo confirma. El patrón está documentado en mi workflow: nunca comprometer cinco pantallas sin saber si el budget las soporta.
La dirección visual tira a operacional, no a consumer-tierno:
- Dispatcher primero. La superficie más usada es el board del dispatcher. Está diseñada para alguien escaneando densidad de información en un monitor de escritorio, no para alguien en el bus al trabajo. La información es densa sin ser ruidosa.
- La superficie del conductor es una herramienta. Los conductores ven un viaje a la vez, con la siguiente asignación en cola. Tap targets grandes. Contraste alto. Funciona con una mano.
- La superficie del pasajero es la cara consumidor. Acá vive la expresión de marca. Más simple, más amigable, más rápida de interactuar, con branding.
- Mobile-first en las tres. Incluso la superficie primaria del dispatcher es responsive; las emergencias suceden cuando el dispatcher no está en el escritorio.
Lo que me llevo
El discovery es una herramienta de expansión de scope, no solo de clarificación. Usado bien, puede convertir “una app para nuestros conductores” en una plataforma de tres lados que el cliente reconoce como el problema real. Usado mal, puede hacer lo contrario, anclando en lo que dijeron originalmente.
Realtime es un presupuesto. Tratar realtime como un gasto finito (no como default) mantiene honestas tanto la arquitectura como el costo operativo.
Las decisiones de hardware suelen estar aguas arriba de la decisión de software. Preguntar “¿shippeamos una PWA o invertimos en tablets?” antes de cualquier línea de código evita que la propuesta colapse seis meses después.
Los mocks gated protegen la conversación de budget. Los mocks Tier 1 aterrizan la propuesta. Los mocks Tier 2 desbloquean cuando el budget se confirma. Esto no es táctica de venta; es disciplina honesta de scope. Los mocks en sí son trabajo que no hago gratis.
Stack
Next.js 16 App Router como PWA, deployado en Vercel. Supabase para Postgres, autenticación, RLS y Realtime. Multi-tenant desde día uno (tabla businesses con RLS aplicando aislamiento de tenant, incluso con un solo tenant en scope actualmente). TailwindCSS para el design system. Sentry para observabilidad. Push notifications vía estándares web-push, sin app nativa requerida.