Estudio de caso

Migración del codebase de un SaaS de flotas multi-tenant

Un SaaS de gestión de flotas y despacho para las empresas de transporte de obra: las que mueven áridos, tierra de excavación y residuos entre obras. Entré como ingeniero senior para dirigir la migración del codebase, white-label a través de una agencia asociada: cuatro años de trabajo constante con clientes ya habían demostrado que el producto funcionaba. Lo que le faltaba era una plataforma capaz de seguirle el ritmo.

Anonimizado bajo NDA: el producto aparece aquí como «Atlas Fleet» y el tenant que se muestra es ficticio.

Laravel 13 (PHP 8.4)Livewire 4Flux UIMySQLReact NativePestFCMNginxSupervisor

El problema

El sistema que me pidieron reemplazar daba servicio a veinte empresas cliente: trabajo real y regulado, con exportaciones a Sage, captura desde la báscula, codificación EWC para residuos regulados y comprobantes en PDF con proof-of-delivery. No era un prototipo.

Lo que lo frenaba era estructural. Dar de alta al cliente número veintiuno significaba otro deploy, y cada arreglo común había que propagarlo veinte veces. El diseño que llevó el producto hasta veinte clientes hacía que el veintiuno saliera caro. Cada cliente corría sobre su propia base de datos, su propia rama de git y su propia carpeta de assets compilados.

kestrel.atlasfleet.app · /login

Laptop con una página de login cubierta por un solo color de marca, con una tarjeta blanca de acceso y el logo de la empresa encima.
[fig. 1] Login de tenant: cada cliente entra por su propio subdominio y la página lleva el color de marca de ese tenant; el branding es una fila en la base de datos, no un build aparte por cliente.

Qué construí

La migración del codebase a Laravel 13 y PHP 8.4 se cerró en menos de cuatro meses: una parte de oficina para planificación y cumplimiento y una app de campo para los conductores; los workflows que el producto había acumulado en cuatro años pasaron intactos.

El cambio de fondo es una sola base de datos compartida: cada registro lleva una cuenta, cada tenant se queda dentro de sus propios datos y el subdominio decide a quién pertenece cada petición.

Siguió siendo un monolito modular a propósito: un solo esquema multi-tenant, queue workers bajo Supervisor y acceso por rol hasta el conductor que entra con un token PIN.

kestrel.atlasfleet.app · /dashboard

Dashboard operativo con seis contadores, una fila de alertas en rojo y ámbar sobre el cumplimiento de los vehículos y una tabla de transportes recientes.
[fig. 2] Las revisiones de la mañana alimentan esa fila: un defecto que un conductor registra a las 6 de la mañana es un aviso ámbar en la oficina a las 6:05.

Planificación por semana, vehículo a vehículo

El corazón operativo de la parte de oficina es un grid de planificación de semana por vehículo.

Los camiones propios aparecen por matrícula, los subcontratistas por su código y los trabajos que aún no tienen vehículo se quedan en una fila ámbar, junto a las revisiones diarias de seguridad, cuyos defectos suben al dashboard de arriba.

kestrel.atlasfleet.app · /operations/planning

Pantalla de planificación con un grid de semana por vehículo: matrículas y códigos de subcontratista a la izquierda, columnas por día con etiquetas de trabajos y una fila ámbar para lo que está sin asignar.
[fig. 3] La planificación. El grid semana × vehículo: la flota propia por matrícula, los subcontratistas por hub code, etiquetas por tipo de transporte (PD, MA, CO, CF) y la fila ámbar de «sin vehículo asignado».

Qué usan los conductores

Una app en React Native, en la que los conductores de los subcontratistas entran con un token PIN, sin cuenta. El conductor arranca un transporte eligiendo el grado de carga del camión y lo cierra con un número de comprobante, una foto y una firma; también ve cuántas toneladas quedan por mover en el proyecto.

¿Estás pensando en migrar tu codebase? El primer paso es que un ingeniero senior lea la versión que tienes ahora. Precio fijo, 1–3 días, informe escrito que se queda contigo.
Empieza con una auditoría

kestrel.atlasfleet.app · driver-app

Dos pantallas de teléfono de la app del conductor: una con los totales de toneladas del proyecto y botones de grado de carga, y otra con el campo de comprobante, el botón de foto, el área de firma y el botón para cerrar el transporte.
[fig. 4] Dos pantallas son toda la app del conductor: se arranca por grado de carga y se cierra con comprobante, foto y firma. Todo lo demás pasa en la oficina.

Qué cambió

  • Una sola base de datos, no una por cliente: todo acotado por cuenta dentro de un solo esquema, en vez de veinte conexiones con nombre.
  • Una sola rama, no una por cliente: se acabó propagar cada arreglo común por veinte ramas.
  • Onboarding: de un deploy a una fila de datos: un servidor, un certificado, una base de datos, una rama.

¿Tienes un codebase que migrar?

Cuéntame qué está crujiendo y cuánto ha crecido. A veces la respuesta es una migración completa; a menudo es un solo cuello de botella que puedes quitar sin ella.

Reserva una llamada gratuita