El legacy que sostiene tu negocio y que nadie quiere tocar
Casi todas las empresas con software propio tienen una aplicación así: lleva años en producción, la usa medio departamento cada día y, sin embargo, nadie en el equipo tiene tiempo —ni ganas— de mantenerla. Suele estar escrita en .NET Framework, WebForms o un MVC antiguo, y funciona… hasta que un día deja de hacerlo.
El problema no es que el código sea viejo. El problema es que no tiene dueño. La persona que lo entendía se fue, la documentación no existe y cada cambio se aborda con miedo.
Señales de que tu aplicación crítica está sin cubrir
- Cuando algo se rompe, nadie sabe con seguridad por qué ni cuánto tardará en arreglarse.
- Los cambios pequeños tardan semanas porque hay que reaprender el sistema cada vez.
- El equipo interno está saturado con el roadmap y el mantenimiento queda siempre para cuando haya un hueco.
- Dependes de una única persona que, si se va de vacaciones, deja un agujero.
Por qué el equipo interno no da abasto
No es falta de talento, es falta de tiempo. Un equipo de producto está para construir lo nuevo; el mantenimiento de una app crítica compite por esas mismas horas y casi siempre pierde. El resultado es deuda técnica que se acumula en silencio hasta que provoca una incidencia cara.
La alternativa: capacidad sénior reservada
La forma sana de sostener una aplicación crítica no es contratar horas sueltas cuando ya está ardiendo, sino reservar cada mes un bloque de horas sénior dedicadas a ella: mantenimiento correctivo, pequeñas evoluciones, decisiones de arquitectura y revisión de código. Cuando algo se rompe, ya hay alguien que conoce vuestro código y tiene el tiempo bloqueado.
Ese modelo convierte el mantenimiento en algo previsible: sabes qué se hace, cuánto cuesta y quién responde. Y libera a tu equipo para lo que de verdad mueve el negocio.