Una sola aplicación para todo el negocio
Reservas, clientes, facturación, traslados, correos y comisiones compartían base de código y base de datos. Es la evolución natural de un negocio que crece: cada necesidad nueva se añadió donde había sitio, y el resultado fue un sistema donde tocar una cosa podía romper otra sin relación aparente.
El problema de fondo no era el código: era que el negocio ya no cabía dentro. Equipos distintos —ventas, operaciones, contabilidad— necesitaban ritmos distintos, y todos dependían del mismo despliegue. Cualquier cambio en contabilidad paraba a ventas.
Nadie puede permitirse un apagón de seis meses
La reescritura desde cero era la opción evidente y la peor: meses sin entregar nada, con el sistema viejo degradándose y el negocio esperando. Se descartó desde el principio.
En su lugar, el monolito se fue vaciando por dominios. Cada área del negocio salió cuando estuvo lista, con sus datos y su ritmo propio, mientras el resto seguía funcionando donde estaba. El sistema antiguo fue perdiendo responsabilidades hasta quedarse sin ninguna.
Ocho dominios, cada uno con su propia aplicación
Reservas e itinerarios
El núcleo del negocio: rutas, etapas, alojamientos, cupos y el itinerario completo de cada peregrino.
Ventas
Cartera por agente, leads, presupuestos, seguimiento y actividad comercial medida.
Operaciones
Lo que ocurre cuando el viaje ya está vendido: bonos, welcome packs, seguros, incidencias y proveedores.
Traslados
Servicio propio de transporte: rutas, conductores, disponibilidad, asignación y costes.
Contabilidad
Gastos, ingresos, facturación, adeudos y remesas bancarias, conciliados contra lo que pasa de verdad.
Finanzas
La capa de dirección: tesorería, previsión y la foto que permite decidir con números.
Comunicaciones
Correo transaccional con el peregrino y con el proveedor, con su trazabilidad y su histórico.
Inteligencia de negocio
Los datos de todos los dominios puestos a trabajar juntos, en lugar de en hojas de cálculo sueltas.
Antes no había trazabilidad de nada
Un monolito no solo mezcla el código: mezcla la responsabilidad. Un traslado se asignaba y ahí se acababa el registro; un gasto vivía en una hoja aparte; el seguimiento de un cliente estaba donde lo hubiera dejado quien lo llevaba. Con eso no se puede auditar nada, ni saber dónde se pierde el dinero.
Al salir por dominios, cada proceso pasó a registrar el suyo. Lo que sigue está medido sobre el mismo tramo del año —del 1 de enero al 22 de septiembre— en 2024 y en 2026.
Traslados
AntesUna fila sin ciclo: sin estado, sin conductor y sin coste.
AhoraConfirmado, completado o cancelado, con conductor, coste y margen por servicio.
Contabilidad
AntesFuera del sistema: ni un apunte registrado.
AhoraMás de 4.600 apuntes de gasto e ingreso en lo que va de 2026, conciliados contra banco.
Ventas
AntesEl seguimiento, donde lo dejara cada agente.
AhoraCada lead y cada presupuesto con agente, etapa y actividad registradas.
Reservas
AntesEl itinerario y los correos, sin registro que consultar.
AhoraUn 15 % más de reservas gestionadas que en 2024, con su itinerario, sus pagos y sus envíos trazados.
Las herramientas con las que trabajan cada día
Capturas del entorno de desarrollo con todos los datos sustituidos por ficticios: clientes, rutas, proveedores, agentes, importes y fechas. Lo que se ve es la estructura, nunca la información del cliente.
Los servidores también son nuestro problema
La plataforma corre sobre cuatro servidores Linux que administramos nosotros: uno local en las oficinas del cliente, dos en la nube y uno dedicado. No es una elección estética: cada carga está donde le conviene por coste, latencia y quién necesita llegar a ella.
No son solo máquinas. El DNS y la capa de borde están en Cloudflare, el correo transaccional sale por Amazon SES, las copias y el almacenamiento interno viven en un NAS Synology de la oficina, los flujos que conectan sistemas corren en n8n, el trabajo se coordina en Asana y los análisis de datos se hacen en Python.
Administrar nosotros los servidores cambia la relación con el proyecto: cuando algo falla a las once de la noche no hay que abrir un ticket con un tercero y esperar. Se entra, se mira y se arregla.
Un proyecto que no se entregó: se sostiene
Tubuencamino no es un encargo cerrado con fecha de entrega. Se trabaja a diario: funcionalidad nueva según lo que pide el negocio, incidencias cuando aparecen, y el mantenimiento de todo lo que ya está en producción.
El proyecto empezó con más manos. Hasta junio de 2026 había otros desarrolladores en los repositorios; desde entonces, el equipo de software de Tubuencamino es Krom. Las aplicaciones en producción, el monolito que queda por jubilar y los cuatro servidores los sostiene hoy una sola persona.
Es el tipo de relación que explica por qué Krom existe. Un sistema que mueve un negocio entero no se termina nunca del todo: se cuida. Y quien lo cuida tiene que entenderlo de arriba abajo, no haberlo leído en una documentación.
¿Tienes un sistema que ya no cabe en sí mismo?
Cuéntanos qué te frena. Si se puede migrar por partes, te decimos por dónde empezar y qué esperar de cada paso.









