Cuando cambiar una cosa rompe todo, el problema empezó antes del código
Hace unos meses me tocó ver una plataforma que, en teoría, ya estaba bastante madura, pero en cuanto querías cambiar una sola regla, se desacomodaba media operación. Y la neta, eso casi nunca empieza en el código; empieza mucho antes, cuando alguien decidió cerrar el negocio demasiado pronto y después le pidió a la tecnología que aguantara todo lo demás.
La rigidez de una plataforma suele decir justo eso: que una lógica de negocio se cerró antes de tiempo, o que metieron supuestos a producción sin haber validado bien hasta dónde llegaba de verdad el servicio. Entonces la tecnología termina reflejando una decisión prematura, no una operación ya aterrizada.
Lo curioso de esto es que hay proyectos que engañan incluso a equipos maduros. El sistema funciona, sí, pero cada cambio cuesta demasiado. A primera vista parece un problema de arquitectura, aunque muchas veces la causa real está en cómo se definió el negocio desde el arranque.
Yo lo vi en una implementación que había nacido para digitalizar una operación existente y luego la empujaron hacia algo distinto a lo que justificó su construcción. El stack podía ser razonable, el equipo competente y la trazabilidad bastante buena. Pero si las reglas cambiaban cada pocas semanas, el coste de tocar cualquier cosa se disparaba. Y ahí ya no era un tema de “hacer mejor código”, sino de que el sistema estaba cargando una volatilidad que no le correspondía.
El síntoma era clarísimo. Un ajuste aparentemente menor obligaba a rehacer diagnósticos, formularios, tablas, cuadros de mando e informes. Backend y frontend tenían que moverse una y otra vez. Eso no significa automáticamente que la arquitectura estuviera mal hecha; más bien te dice que se empezó a codificar una lógica operativa cuando todavía no estaba madura.
Esa diferencia importa mucho. Una arquitectura puede absorber cierta incertidumbre, pero no puede sustituir un proceso de decisión que sigue abierto. Si el modelo de monetización, el alcance del servicio o la naturaleza del producto todavía se están redefiniendo, la tecnología deja de acelerar y pasa a sostener dudas.
Un CTO debería mirar justo ahí. El retrabajo no siempre apunta a una mala implementación. A veces señala una secuencia equivocada: primero se construyó y luego se intentó decidir qué negocio había detrás. Y entre más tiempo pasa, más caro sale corregir esa secuencia.
El caso lo resumía bastante bien. La propuesta inicial era simple: diagnóstico, cobro y cierre. Después apareció la idea de convertirlo en un servicio recurrente, con pagos periódicos, pasarelas internas y otra relación comercial. Técnicamente se podía hacer. Pero estratégicamente ya era otra compañía. Y cuando intentas meter ese salto sobre una plataforma nacida para otra cosa, el coste de cambio deja de ser técnico y se vuelve contractual, operativo y financiero.
La lección, al final, es bastante incómoda: si cambiar una decisión rompe media plataforma, la pregunta no es solo cómo refactorizar. También hay que revisar qué hipótesis de negocio se codificaron antes de tiempo. Una arquitectura puede aguantar incertidumbre por un rato, pero no puede convertir una indefinición estratégica en velocidad. ¿Y cuántas veces no pasa justo al revés?
