Un sistema de gestión para una cartera de alojamientos de corta y larga estancia: reservas, clientes, facturación y los canales de venta por los que llegan las estancias.
Un calendario de reservas con lo operativo enganchado: clientes y sus documentos, facturación por estancia, y un catálogo fijo de canales de venta —cada uno se activa o se desactiva y lleva su propia comisión—. Los canales no son nombres que alguien tecleó: cada uno es un driver que la aplicación conoce, y por eso más adelante pudo hablar el protocolo de calendario de esos portales.
Multiusuario desde el primer día, así que los problemas interesantes nunca fueron los del CRUD: quién puede cambiar qué, cómo se demuestra después qué se cambió, y cómo llega una release a la instancia en marcha sin un instante a medio aplicar en el que la carcasa es nueva y la API vieja.
Mayo — que funcione. El calendario, filas de reserva desplegables que se editan sin salir, componentes de campo reutilizables, y un sistema de diseño extraído del SCSS disperso una vez la forma se asentó. Dos idiomas antes de acabar el mes.
Junio — que sea fiable. Autorización aplicada en vez de supuesta, y un registro de auditoría inmutable: cada cambio aceptado deja constancia y nadie puede retocarla sin que se note.
Agosto — que aguante. La persistencia pasó de ficheros JSON a SQLite embebido con una conversión puntual, y el servidor se niega a arrancar contra un esquema que no reconoce. Los roles pasaron a ser cuatro, con el permiso decidido en la ruta. El despliegue dejó de ser un paso manual. Después llegaron la sincronización bidireccional de calendarios y una bandeja pública de solicitudes, que convirtieron una herramienta interna en algo con lo que habla el mundo exterior — y eso, a su vez, es la razón de que una contraseña dejara de ser toda la respuesta.
El arco, en una línea: un CRUD en mayo; en septiembre, un sistema con trazabilidad, camino de migración, tubería de release y doble factor.
Una contraseña ya no es toda la respuesta. Cualquier cuenta puede pedir un código de seis dígitos enviado a su propia dirección, opcional y activable desde el perfil. Un administrador puede quitárselo a quien pierda el acceso al buzón donde llega.
Un canal dejó de ser un nombre tecleado y pasó a ser un driver que la aplicación conoce, con su propia marca y su comisión. Las estancias directas también son un canal: sin intermediario, sin comisión y no se pueden borrar.
Lee los calendarios de los canales y publica el propio, así que una estancia reservada en cualquier sitio bloquea las fechas en todos. Además, una bandeja para las solicitudes que llegan de la web pública y un endpoint de disponibilidad de solo lectura que esta puede consultar.
Las comprobaciones de permiso se movieron a donde se atiende la petición, en vez de estar repartidas por la interfaz. Un rol se cambia, una cuenta se borra, un correo se guarda: tres operaciones distintas que antes eran una sola, borrosa.
Se ejecutan los tests, se construye y publica la imagen, se redespliega la instancia, y la tubería espera al health check y confirma la versión desplegada antes de darlo por hecho. Hay una instancia de desarrollo aparte, sembrada con datos reales. La carcasa de la SPA se sirve con no-store, de modo que un despliegue nunca puede quedarse a medio aplicar en el navegador de nadie.
SQLite embebido en lugar de ficheros en disco, con una conversión puntual para los datos existentes y el esquema colapsado en una sola migración antes del lanzamiento. El servidor se niega a arrancar contra un esquema que no reconoce, en vez de corromper uno que entiende a medias.
El límite de intentos de login se ancla a una IP de cliente que no se puede falsificar. Un cuerpo malformado responde 400, no 500. Los errores que llegan arriba se registran en vez de convertirse en un 500 silencioso. Dos fallos que los tests no podían ver aparecieron al ejecutar contra el contenedor real.
Cada cambio aceptado escribe un registro inmutable. La autorización dejó de ser una suposición sobre quién llega a una pantalla y pasó a ser una regla que el servidor hace cumplir.
Reconstruida para que los números se lean de un vistazo, y arreglados el recorte de filas y los rangos de fechas que encogían en pantallas estrechas.
Inglés y castellano con vue-i18n, el SCSS disperso centralizado en una capa de estilos, los SVG en línea sustituidos por assets reales, y subcomponentes de campo reutilizables para que editar se comporte igual en todas partes.
Filas de reserva desplegables que se editan sin abandonar el calendario, una pantalla de administración de clientes, autogestión por usuario, y la jerarquía de navegación que la aplicación sigue usando.
Un monorepo, un servidor Node, un cliente Vue, y una reserva que se podía anotar.