Todo VP de Ingeniería ha pasado por esa reunión. La revisión de la hoja de ruta va bien hasta que alguien pregunta por qué una funcionalidad sencilla tardó tres sprints en lugar de uno. El ingeniero responde algo sobre código legado, acoplamiento excesivo y un esquema de base de datos que nadie quiere tocar. El CFO asiente, pasa al siguiente punto y el momento se esfuma. Ninguna parte de esa respuesta llevaba una cifra asociada, y los equipos de finanzas no aprueban presupuesto para una sensación, por firme que sea.
Este es el fallo de fondo de toda conversación sobre deuda técnica que se mantiene en lenguaje de ingeniería en lugar de en lenguaje financiero. Los ingenieros describen la deuda como un problema de calidad. Los equipos de finanzas financian los problemas de calidad a regañadientes, cuando lo hacen. Pero sí financian sin pestañear el lastre sobre el crecimiento, la erosión del margen y el riesgo de balance, porque esas son las categorías que un CFO cobra por gestionar.
Así que este artículo le da la cifra: un modelo de dos capas para calcular el coste de la deuda técnica en dólares. Primero, las horas de ingeniería que su equipo pierde cada sprint. Después, cuatro costes que finanzas ya entiende: ingresos retrasados, clientes perdidos, facturas de contratación más altas y un precio más bajo en la salida. No necesita herramientas nuevas para aplicarlo, porque los datos de entrada salen de sus retrospectivas de sprint, su registro de incidencias y su última revisión de código.
Lo que dice la investigación independiente sobre el coste de la deuda técnica
Antes de modelar su propia cifra, conviene saber qué han medido otros. Hay tres estudios que merece la pena citar en una reunión con finanzas.
El análisis de Deloitte de 2026 sitúa la deuda técnica entre el 21% y el 40% del gasto en TI de una organización, y usa el 30% como punto medio de trabajo. Sobre un presupuesto anual de TI de 10 millones de dólares, eso son de 2,1 a 4 millones de dólares al año que se destinan a trabajo de deuda en lugar de a nuevas capacidades.
McKinsey encuestó a 50 CIO de empresas de servicios financieros y tecnológicas con ingresos superiores a 1.000 millones de dólares. Esos CIO estimaron la deuda técnica en entre el 20 y el 40 por ciento del valor de todo su parque tecnológico antes de amortizaciones. En términos sencillos: sume cuánto valen todos sus sistemas, y entre una quinta parte y dos quintas partes de esa cifra es trabajo que sigue debiéndose, es decir, los arreglos y las actualizaciones que tienen que ocurrir antes de que esos sistemas estén en la forma que el negocio realmente necesita. Esos mismos CIO declararon que entre el 10 y el 20 por ciento del presupuesto reservado para productos nuevos se desvía a trabajo de deuda antes de que se entregue una sola funcionalidad, y un 60 por ciento dijo que el problema había crecido de forma notable en los tres años anteriores.
A escala nacional, el Consortium for Information and Software Quality estimó la deuda técnica acumulada en la economía del software de EE. UU. en unos 1,52 billones de dólares, parte de un coste total de 2,41 billones de dólares por mala calidad del software.
Use estas cifras como prueba de coherencia para su propio modelo, no como sustituto de él. Si su número sale muy por debajo del 20 por ciento del gasto en ingeniería, sus datos de entrada probablemente son demasiado optimistas, y su CFO se dará cuenta antes que usted. Las métricas que alimentan esos datos las cubrimos en nuestra guía para medir la deuda técnica.
El modelo de costes listo para el CFO
El modelo tiene dos capas. La primera es un coste directo que puede calcular con datos que ya tiene. La segunda es un conjunto de costes indirectos que requieren algunas estimaciones razonables, y eso está bien, porque los CFO se manejan cómodamente con rangos estimados siempre que la metodología sea transparente. Así es como ya tratan la amortización, las provisiones por insolvencias y casi todo lo demás del balance.
Capa 1: el coste directo que puede calcular hoy
Coste directo = horas perdidas por sprint a causa de la deuda × coste cargado por hora de ingeniería × sprints al año
- Horas perdidas por sprint. Extráigalas de las retrospectivas de sprint, del control de tiempos o de una encuesta de dos semanas que pregunte qué proporción de los story points se fue a retrabajo provocado por la deuda en lugar de a trabajo nuevo. Si aún no tiene datos internos, empiece por el extremo conservador del rango de la investigación, el 20 por ciento, y sustitúyalo por su propia cifra en uno o dos sprints. Una cifra salida de sus propias retrospectivas siempre resistirá mejor el escrutinio que una media del sector.
- Coste cargado por hora de ingeniería. El coste cargado es todo lo que un ingeniero le cuesta a la empresa en un año, no solo lo que llega a su cuenta bancaria: salario base más beneficios, impuestos sobre nómina, equipamiento, licencias de software, reclutamiento y una parte de los gastos generales de oficina y administración. Finanzas ya lo calcula para cada puesto, así que pida su cifra en lugar de estimarla usted.
- Sprints al año. Normalmente de 24 a 26 con una cadencia de dos semanas.
Este es el cálculo paso a paso, para un equipo de diez ingenieros:
- Capacidad del equipo por sprint. Diez ingenieros trabajando un sprint de dos semanas dan 800 horas en total, que son 10 personas × 80 horas cada una.
- Coste por hora. Supongamos que el coste cargado es de 145.000 dólares por ingeniero al año. Divídalo entre 2.080 horas de trabajo, que es el año estándar a tiempo completo de 40 horas semanales × 52 semanas, y obtiene unos 70 dólares la hora.
- Horas perdidas a causa de la deuda. Con un 35 por ciento, 280 de esas 800 horas se van a trabajo de deuda cada sprint.
- Coste de un sprint. 280 horas × 70 dólares = 19.600 dólares.
- Coste del año. 19.600 dólares × 26 sprints = unos 510.000 dólares.
Esos 510.000 dólares son tiempo de ingeniería dedicado a servir la deuda en lugar de a construir producto, y nunca han aparecido en una sola partida contable. Suele hacer que un CFO escéptico se incline hacia delante, porque es un gasto operativo real que nadie estaba midiendo. Para que el dato de horas sea más difícil de discutir antes de la reunión, afine cómo su equipo define y mide la calidad del código.
Capa 2: los costes indirectos que hacen que finanzas preste atención
Los costes indirectos son lo que la deuda técnica le hace al resto del negocio: ingresos que llegan tarde, clientes que se van tras una caída de más, salarios que paga por encima de mercado para cubrir un sistema envejecido.
Funcionalidades retrasadas
Valor de la funcionalidad por semana × semanas de retraso causadas por la deuda
Proyecciones de la hoja de ruta, histórico de entregas
Churn por incidentes
Clientes perdidos por incidente grave × valor de vida medio del cliente
Tickets de soporte, registro de incidencias, informes de churn
Sobrecoste de contratación
Tiempo de contratación adicional y tasa de ofertas rechazadas en puestos legados frente a puestos modernos
Datos del embudo de reclutamiento
Descuento en la valoración
Presupuesto de remediación probable del equipo de due diligence de un comprador
Hallazgos de due diligence previos, informes de auditoría
Funcionalidades retrasadas. Tome los ingresos o el ahorro de costes previstos de la funcionalidad, divídalos entre su plazo planificado para obtener un valor por semana y multiplíquelo por el retraso atribuible al retrabajo provocado por la deuda. Una funcionalidad que vale 40.000 dólares al mes y se entrega ocho semanas tarde por restricciones del código legado supone unos 80.000 dólares de valor diferido, totalmente al margen de las horas de ingeniería quemadas para llegar hasta ahí.
Churn por incidentes. Use su tasa de fallos por cambio, la proporción de despliegues que provocan un incidente, un rollback o un hotfix, junto con los datos de soporte y de churn para estimar cuántos clientes pierde por incidente grave, y multiplíquelo por el valor de vida del cliente. La mayoría de los equipos encuentra esta cifra mayor de lo esperado, porque los incidentes casi nunca se rastrean hasta la deuda que los causó.
Sobrecoste de contratación. Si su sistema necesita una versión antigua de un framework, una herramienta interna a medida o un lenguaje obsoleto, compare el tiempo de contratación y la aceptación de ofertas de esos puestos con los de su stack moderno. La penalización es real por dos razones: la bolsa de ingenieros que aún conocen una tecnología desfasada se reduce cada año, y los que sí la conocen a menudo rechazan el puesto porque aceptarlo estrecha su siguiente movimiento profesional. Eso lo paga dos veces, en una vacante más larga y en una oferta más alta.
Descuento en la valoración. Si hay una salida, una adquisición o una ronda en el horizonte, modele un descuento conservador basado en el coste de remediación que presupuestaría el equipo de due diligence técnica de un comprador. Es el más difícil de precisar de los cuatro, pero incluso un rango aproximado convierte la deuda de una queja de ingeniería en un asunto de valor para el accionista. Nuestro checklist de due diligence técnica en M&A muestra qué buscan realmente esos equipos, lo que hace la estimación mucho menos especulativa.
Sume las cuatro estimaciones indirectas al coste directo y tendrá una sola cifra anualizada: el coste de la deuda técnica de su organización, en dólares y no en story points. Qué hacer con ella es la siguiente decisión, y tener la cifra es lo que hace posible esa decisión. Pasar el mantenimiento rutinario, como las actualizaciones de dependencias, la cobertura de regresión y los parches de seguridad, a un contrato de mantenimiento de software es una de las vías habituales, porque convierte un coste impredecible en una partida fija que finanzas puede prever.
Dónde el código asistido por IA cambia las cuentas
Si su equipo entregó bastante más código este año con la misma plantilla, su cifra de horas de deuda del año pasado ya está desfasada. El desarrollo asistido por IA mueve el cuello de botella de escribir código a revisarlo, y el código que pasa la revisión con demasiada facilidad tiene la costumbre de volver como retrabajo un trimestre después. Explicamos cómo se acumula esa deuda en nuestro artículo sobre la deuda técnica en el código generado con IA.
Dos cambios mantienen su modelo de costes preciso. Vuelva a medir la cifra de horas de deuda de la capa 1 cada trimestre en lugar de cada año, y sígala junto con la proporción de código fusionado que fue asistido por IA. Si esas dos cifras suben juntas, ha encontrado su fuente de deuda de crecimiento más rápido mientras todavía es barato abordarla. Los equipos que ya usan herramientas de revisión con IA también deberían comprobar qué detectan realmente esas herramientas, que es lo que probamos en nuestra reseña de Claude Code para revisión de código.
Cuando una base de código ya ha acumulado un backlog de código generado por IA que nadie asume del todo, una intervención enfocada de limpieza de vibe code suele ser más barata que absorber ese trabajo en la capacidad normal del sprint, porque el alcance está acotado y se puede presupuestar contra la cifra que acaba de calcular.
Por qué los equipos incorporan a Redwerk a esta conversación
Redwerk construye software desde 2005, así que hemos visto acumularse mucha deuda y nos han contratado para limpiar una buena parte de ella. Construimos productos complejos desde cero, auditamos sistemas que nadie ha documentado en años y refactorizamos proyectos legados que otros equipos abandonaron. Más recientemente hemos añadido a ese trabajo soluciones potenciadas por IA y desarrollo y testing asistidos por IA. Los fundamentos de ingeniería y las prácticas de seguridad que hay detrás son los mismos que hemos aplicado para clientes de Norteamérica y Europa, incluidas empresas del Fortune 500 como Siemens, J.B. Hunt y Universal Music Group. Ahora cubren también las fuentes de deuda más recientes.
El ahorro suele empezar más pequeño y más pronto de lo que la gente espera. Cuando Adoorabelle, un marketplace inmobiliario de Atlanta, nos incorporó, el fundador no era técnico, estaba atado a un proveedor anterior y no tenía documentación que mostrar a un inversor. Nuestra auditoría de su aplicación inmobiliaria detectó 80 problemas, desde secretos escritos en el código hasta fallos estructurales críticos, eliminó 300 dólares al mes de suscripciones a API innecesarias, que son 3.600 dólares al año recuperados del presupuesto operativo solo por eso, acercó su infraestructura de AWS a sus usuarios y añadió observabilidad 24/7 con Sentry, Prometheus y Grafana. Terminaron con una especificación funcional completa, independencia total del proveedor y algo que mostrar a los inversores.
Ese es el patrón que merece la pena copiar: averiguar qué cuesta realmente la deuda, en dólares, antes de decidir cuánto gastar en ella. Si quiere esa cifra elaborada por gente que además le dirá con claridad qué partes no merece la pena arreglar, empiece por una auditoría de desarrollo de software.
Preguntas frecuentes
¿Cuánto cuesta la deuda técnica?
No hay una cifra única del sector, porque depende del tamaño del equipo, del coste de ingeniería y de cuánta deuda arrastra la base de código. La investigación independiente da anclas útiles: Deloitte sitúa la deuda técnica entre el 21% y el 40% del gasto en TI, y McKinsey vio a los CIO estimándola entre el 20 y el 40 por ciento del valor total de su parque tecnológico. Aplicar su propio coste cargado de ingeniería a las horas de deuda por sprint de su equipo es la única manera de obtener una cifra específica de su empresa en lugar de una media del sector.
¿Cómo se estima el coste a largo plazo de la deuda técnica?
Combine un coste directo, que son las horas perdidas por sprint a causa de la deuda multiplicadas por el coste cargado de ingeniería y por los sprints al año, con cuatro costes indirectos: el coste de oportunidad de las funcionalidades retrasadas, el churn ligado a la frecuencia de incidentes, los sobrecostes de contratación para talento de stacks legados y cualquier descuento en la valoración que afloraría en una due diligence técnica. Como la deuda se acumula, modele el total de forma anual y revise los datos de entrada cada trimestre en lugar de tratarlo como un cálculo puntual.
¿Cómo calculan las empresas el coste de la deuda técnica?
La mayoría de las organizaciones de ingeniería maduras sigue una cifra de horas de deuda por sprint a partir de las retrospectivas o del control de tiempos, aplica el coste cargado por ingeniero que calcula su equipo de finanzas y añade métricas de entrega como la tasa de fallos por cambio y el tiempo de recuperación para conectar la deuda con los costes de incidentes y de churn. El resultado suele expresarse como una cifra anualizada en dólares junto con un porcentaje de la capacidad total de ingeniería.
¿Por qué los CFO rechazan las solicitudes de presupuesto para deuda técnica?
La mayoría de las solicitudes se plantean en términos de ingeniería, como calidad del código, refactorización y arquitectura, en lugar de en términos financieros como dólares, coste de oportunidad y exposición al riesgo. Una solicitud planteada como “510.000 dólares en tiempo de ingeniería anual más 600.000 dólares en churn e ingresos retrasados previstos” compite por presupuesto igual que cualquier otra decisión de asignación de capital. Una solicitud planteada como “el código necesita una limpieza” normalmente no.
Descubre cómo Redwerk se hizo cargo de una aplicación de fitness con dificultades que venía de otro proveedor, resolvió la deuda técnica heredada y ayudó a Pridefit a aumentar sus suscripciones un 45%
