deuda técnica silenciosa: cómo saber si tu aplicación está hipotecando tu negocio.

Tu aplicación funciona. Los clientes entran, el equipo entrega, nada está en llamas. Y sin embargo, cada cambio cuesta un poco más que el anterior: el ajuste que antes tomaba dos días ahora toma dos semanas, y nadie puede explicarte exactamente por qué. Eso tiene nombre — deuda técnica — y aunque no aparece en ningún balance, te está cobrando intereses todos los meses.

La deuda técnica no es un error ni una vergüenza. Es el resultado natural de decisiones correctas en su momento: salir rápido al mercado, validar con lo mínimo, postergar lo que no era urgente. Todo MVP que llegó a tener clientes la tiene. El problema no es tenerla — es no saber cuánta tienes, dónde está concentrada ni cuánto te cuesta por mes. Esa es la diferencia entre una hipoteca que elegiste y una que descubres en la escritura.

"La deuda técnica no se ve en el producto. Se ve en el calendario: cada mes, lo mismo cuesta más."

// // las cuatro señales que puedes ver sin leer código

No necesitas saber programar para diagnosticar esto. Las señales son operacionales y financieras, y viven en información que ya tienes — o que puedes pedir hoy mismo.

señal 01 : cada feature tarda más que la anterior

Hace un año tu equipo lanzaba mejoras todas las semanas. Hoy, con la misma gente o más, una funcionalidad comparable se arrastra por sprints completos. Si el equipo no cambió y el producto no se volvió radicalmente más ambicioso, la explicación más probable es que el costo de modificar el sistema está subiendo. Ejercicio simple: lista qué se lanzó hace doce meses y compáralo con el último trimestre. Si la pendiente baja con el mismo equipo, tienes la primera señal.

señal 02 : miedo a tocar el código

Se reconoce en frases: 'mejor no tocamos esa parte', 'eso lo hizo alguien que ya no está', 'si funciona, no lo movamos'. Ese miedo es información valiosa: significa que no existen pruebas automáticas ni documentación que permitan cambiar el sistema con confianza. Y un sistema que nadie se atreve a tocar no es estable — es frágil con buena suerte.

señal 03 : una sola persona lo sabe todo

En jerga técnica se llama bus factor: ¿cuántas personas tienen que faltar para que nadie pueda mantener el sistema? Si la respuesta es una, tu aplicación no es un activo de la empresa — es un activo de esa persona. Eso condiciona vacaciones, licencias, renuncias y, seamos honestos, también la negociación de tarifas. 'Mi desarrollador renunció y nadie más entiende la aplicación' es una llamada que existe en el mercado chileno, y siempre llega en el peor momento.

señal 04 : la factura cloud crece sin razón

Si tu cuenta de infraestructura — AWS, Google Cloud, Vercel, la que uses — sube mes a mes pero tus usuarios y ventas no suben al mismo ritmo, algo consume recursos de forma ineficiente: consultas sin optimizar, servidores sobredimensionados, servicios que nadie apagó. No necesitas saber cuál es la causa. La divergencia entre factura y crecimiento es, por sí sola, la señal. Pide el desglose de los últimos seis meses y ponlo al lado de tu curva de usuarios.

// // cuánto te está costando : haz esta cuenta

No te voy a dar un porcentaje de la industria, porque sería inventarlo. Haz la cuenta con tus propios números — es más incómodo y mucho más útil. Son tres líneas:

• -costo directo: lo que pagas al mes a tu equipo técnico, multiplicado por la fracción de su tiempo que se va en arreglar cosas que ya estaban 'listas' y en pelear contra el sistema. Pregúntales la fracción directamente; la respuesta te va a sorprender.
• -costo de oportunidad: las funcionalidades que no se lanzaron este trimestre por estar apagando incendios. ¿Cuánto valía esa mejora de conversión, ese canal nuevo, esa integración que pedía un cliente grande?
• -prima de riesgo: qué pasa con tu facturación si el sistema se cae en tu peak de ventas, o si la única persona que lo entiende renuncia con 30 días de aviso.

Para dimensionar el resultado: en mi lista de precios, un proyecto de desarrollo profesional parte en $1.000.000 CLP, un e-commerce de nivel competitivo desde $6.5 millones y un sistema con IA desde $8.5 millones. Si tu cuenta de arriba supera esas cifras por trimestre, ya estás pagando el proyecto — solo que en la forma más cara posible: en retrabajo, y sin recibir un activo a cambio.

// // qué entrega una auditoría técnica (de verdad)

Una auditoría técnica seria no es un PDF de 40 páginas de jerga para justificar una factura. Es una traducción: del estado real de tu sistema al lenguaje en que tomas decisiones de negocio. Esto es lo que deberías exigir como entregables:

• -mapa de arquitectura en lenguaje de negocio: qué piezas existen, qué hace cada una, cuáles sostienen la facturación y cuáles son frágiles.
• -mapa de riesgos priorizado: qué puede botar la operación mañana versus qué es deuda cosmética que puede esperar un año.
• -plan de remediación por etapas, ordenado por impacto y costo, que cualquier equipo competente pueda ejecutar — no solo quien lo escribió.
• -medición del bus factor: qué conocimiento crítico vive en una sola cabeza y cómo se documenta antes de que sea urgente.

Y las señales de alerta al contratar una: desconfía de quien recomienda reescribir todo sin haber leído el código, de los informes que no entiendes sin traductor, y de los diagnósticos cuyo plan de acción solo puede ejecutar el mismo que diagnosticó.

// // ¿rescatar o reescribir?

Cuando la deuda duele, la tentación es partir de cero. Es la decisión más cara que puede tomar una empresa con un producto funcionando, y casi siempre es la equivocada. Reescribir significa congelar la evolución del sistema actual durante meses mientras construyes su reemplazo — y el reemplazo hereda todas las reglas de negocio no documentadas que el sistema viejo aprendió a golpes.

• -rescata si: el núcleo funciona y los problemas están en los bordes; hay clientes activos que no puedes congelar; la deuda está concentrada en módulos identificables.
• -reescribe solo si: la tecnología de base ya no recibe soporte ni parches de seguridad; el costo de cada cambio supera demostrablemente el de construir de nuevo; o el negocio pivoteó tanto que el sistema actual modela una empresa que ya no existe.

El default racional es el rescate incremental: estabilizar lo crítico, documentar lo que vive en una sola cabeza y modernizar por módulos mientras el negocio sigue operando. Es menos épico que la reescritura heroica. También es lo que mantiene la facturación viva durante el proceso.

// // qué hacer esta semana

• -pide acceso al repositorio de código y a la facturación cloud, o que te los muestren — son activos de tu empresa, no del proveedor.
• -haz la cuenta de tres líneas con tus números reales y tenla a mano en la próxima reunión de roadmap.
• -pregunta a tu equipo, sin juicio, qué parte del sistema les da miedo tocar — y por qué.
• -si encontraste dos o más señales, consigue una segunda opinión independiente antes de firmar más desarrollo encima de lo que ya hay.

Si quieres ver cómo trabajo: en /servicios está el detalle de los protocolos de desarrollo y rescate, y en /proyectos los sistemas que tengo en producción. La deuda técnica no se paga sola — pero tampoco se diagnostica sola.