PWA de autogestión de operaciones de vehículos

Problema

La ruta de autogestión seguía suponiendo un mostrador con personal o un sitio móvil frágil. Los propietarios no podían completar el ciclo principal desde un teléfono. Las herramientas de operaciones adyacentes (back-office, pickers y apps de cliente) se habían desalineado de versión, así que un cambio en una superficie no sobrevivía en las otras.

Restricciones

El producto tenía que publicarse como PWA, no como app de tienda. Los sistemas existentes de identidad y pólizas seguían siendo la fuente de verdad; reescribirlos quedaba fuera de alcance. La cobertura de tests tenía que subir con la reconstrucción, no después. Este texto no describe a la aseguradora, el catálogo de vehículos ni ninguna interfaz de producción.

Arquitectura

La versión 2.0 de la superficie para el propietario se construyó desde cero en React como PWA: instalable, tolerante a la ausencia de red para la última sesión conocida y dirigida por un cliente de API tipado. Una capa compartida de componentes y contratos mantenía el back-office, los pickers y las apps de cliente en la misma línea de versión. El TDD cubría cerca de tres cuartos del trabajo nuevo, de modo que las regresiones del ciclo del propietario no pudieran esconderse en las herramientas de operaciones. Un quiosco Electron aparte atendía la interacción presencial sin compartir el enrutado de la PWA.

Rol

Como líder técnico de frontend me encargué de la reconstrucción de la PWA, de la capa de contratos compartida entre las tres superficies de operaciones y de la disciplina de tests que hacía seguro ese reparto. También publiqué el quiosco Electron como una ruta presencial distinta.

Resultados

• Los propietarios podían completar el ciclo de autogestión desde un navegador, sin una instalación nativa.
• Back-office, pickers y apps de cliente se movían como una versión, no como tres forks.
• Un TDD que cubría cerca del 75 % del trabajo nuevo hacía exigibles los contratos compartidos.

Stack