El precio de un software no es lo que cuesta construirlo, sino lo que cuesta poseerlo durante los años que va a estar en producción. Construir se ha vuelto barato; operar, corregir, integrar y evolucionar no. Comparar dos propuestas por su presupuesto de entrega es como comparar dos edificios por el coste del hormigón.
Esta distinción se ha vuelto urgente en los últimos dieciocho meses. El coste de producir código ha caído de forma real y verificable —Stanford HAI documentó que el coste de inferencia para un sistema equivalente a GPT-3.5 se dividió por más de 280 entre noviembre de 2022 y octubre de 2024—, y con él ha caído el precio de entrada de muchas propuestas de desarrollo. Lo que no ha caído es el coste de mantener en pie lo que se construye.
El presupuesto de un proyecto suele cubrir análisis, diseño, desarrollo y puesta en producción. Es entre el 30% y el 40% del dinero que ese sistema va a consumir en su vida útil. El resto aparece después, repartido en partidas que casi nunca están en la propuesta inicial:
Partida | Qué incluye | Cuándo aparece |
Construcción | Análisis, diseño, desarrollo, despliegue | Meses 1-9 |
Infraestructura | Cloud, almacenamiento, backups, entornos | Desde el día 1, para siempre |
Corrección | Defectos, regresiones, incidencias en producción | Desde la primera semana |
Evolución | Cambios de negocio, nuevos requisitos, nuevas integraciones | Continuo |
Seguridad y compliance | Parches, auditorías, adaptación normativa | Continuo, con picos regulatorios |
Dependencia | Coste de que solo un proveedor sepa tocarlo | Aparece cuando quieres cambiar |
Las cinco primeras partidas se pueden estimar. La sexta no aparece en ningún presupuesto y es la que más dinero cuesta cuando se materializa, porque no se paga en euros al principio: se paga en pérdida de capacidad de negociación.
La deuda técnica se explica normalmente como un concepto de ingeniería, y por eso los comités de dirección la ignoran hasta que es tarde. En términos financieros es más simple: es el sobrecoste que pagas cada vez que quieres cambiar algo, derivado de decisiones tomadas para ir más rápido en su momento.
Las estimaciones del sector sitúan la carga de mantenimiento y deuda tecnológica en torno al 40% del presupuesto de TI de una organización media. Es una cifra que conviene tratar como orden de magnitud, no como dato auditado, porque las metodologías varían mucho entre estudios. Pero la dirección es consistente en todas las fuentes: la mayor parte del gasto en tecnología de una empresa establecida no financia capacidades nuevas, financia el mantenimiento de decisiones antiguas.
Hay un dato adicional que cambia la conversación cuando se plantea a un director financiero: IBM estima que sanear la deuda técnica de los sistemas heredados puede mejorar el retorno de las iniciativas de inteligencia artificial hasta un 29%. Es decir, la deuda técnica no solo cuesta dinero en mantenimiento: reduce el rendimiento de todo lo que se construya encima.
Y el problema está creciendo, no reduciéndose. GitClear, sobre un análisis de 211 millones de líneas de código, documentó que la duplicación de bloques de código se disparó a partir de 2024 y que el trabajo de refactorización —la actividad que paga deuda— cayó de aproximadamente el 25% del cambio total en 2021 a menos del 10% en 2024. Se construye más rápido y se limpia menos.
No hace falta una auditoría formal para detectar los primeros síntomas. Estos son los indicadores que aparecen antes:
Cuando aparecen tres o más de estos síntomas, añadir capacidad de desarrollo no acelera nada. Solo aumenta el número de personas esperando a que se resuelva una decisión de diseño.
Cuando compares proveedores, estas cuatro preguntas separan a quien vende una entrega de quien vende un sistema. Ninguna es técnica; todas son contractuales.
¿De quién es el código? Si la respuesta incluye matices, licencias o «acceso al repositorio», la respuesta es que no es tuyo. La propiedad del código, la documentación y la propiedad intelectual deben transferirse por contrato. Sin eso, cualquier presupuesto es provisional, porque el proveedor tiene poder de fijación de precios indefinido sobre tu operación.
¿Qué pasa si mañana quiero cambiar de proveedor? La respuesta útil no es «no lo harás». Es: existe documentación de arquitectura, los módulos exponen contratos versionados, hay entornos separados y cualquier equipo competente puede hacerse cargo en un plazo razonable. Si esa transición requiere que alguien del proveedor original «explique cómo funciona», el sistema no está documentado, está memorizado.
¿Quién paga los defectos? Un defecto en el código entregado no es un cambio de alcance. Debería corregirse sin coste, y eso debería estar por escrito. En The Cloud Group lo llamamos Garantía Lluvia y está en el contrato: los defectos del código entregado los corregimos nosotros, de por vida. No es generosidad, es coherencia: si defiendes que tu ingeniería es disciplinada, tienes que asumir el coste de que no lo sea.
¿Cuál es el coste de operación estimado a tres años? Cualquier proveedor serio puede darte un rango de infraestructura, soporte y evolución. Quien no puede darlo, o no lo ha pensado, o prefiere que no lo pienses tú.
Estas preguntas son exactamente las que ayudamos a formular cuando actuamos como parte independiente en un proceso de selección de proveedores y redacción de RFP [enlace interno], sin participar como candidatos en la licitación que evaluamos.
No es una coincidencia, es una relación causal. Las decisiones que abaratan la construcción son casi siempre las que encarecen el mantenimiento:
Ninguna de estas decisiones es visible en una demo. Todas son visibles en la factura del tercer año.
El caso opuesto también existe y es medible. En proyectos de modernización de sistemas heredados —auditar, refactorizar y modernizar en lugar de reescribir desde cero— hemos visto reducciones de costes de mantenimiento de hasta un 60%. No porque el código nuevo sea mágico, sino porque el coste de mantenimiento es en gran parte el coste de la incertidumbre: cuando el sistema es comprensible y está probado, cada cambio deja de ser una apuesta.
El error habitual del equipo técnico es pedir presupuesto «para pagar deuda técnica». Es una petición que ningún comité aprueba con entusiasmo, porque suena a arreglar algo que se hizo mal.
La formulación que funciona es distinta y es honesta:
La conversación deja de ser «el software está mal hecho» y pasa a ser «esta es la diferencia de coste entre las dos rutas». Esa segunda conversación se puede ganar.
Una propuesta barata que no incluye propiedad del código, documentación, pruebas ni contratos de integración no es una propuesta barata: es un préstamo con un tipo de interés que descubrirás después.
La pregunta que conviene llevar a la próxima decisión de compra de software no es cuánto cuesta construirlo. Es cuánto cuesta poseerlo, quién es su dueño y qué pasa el día que quieras cambiar de opinión.
Es la suma de todo lo que cuesta un sistema durante su vida útil: construcción, infraestructura, corrección de defectos, evolución funcional, seguridad y compliance, y el coste de depender de un único proveedor. El presupuesto de construcción suele representar solo entre el 30% y el 40% del total.
Las estimaciones del sector lo sitúan en torno al 40% del presupuesto de TI, aunque la cifra varía según la metodología del estudio. La dirección es consistente: en empresas establecidas, la mayor parte del gasto tecnológico mantiene decisiones pasadas en lugar de crear capacidades nuevas.
Estima al menos tres años de vida e incluye seis partidas: construcción, infraestructura y entornos, corrección de defectos, evolución funcional, seguridad y adaptación normativa, y coste de salida o cambio de proveedor. Un proveedor serio puede darte un rango razonado de las cinco primeras.
Porque las decisiones que abaratan la construcción —saltarse el diseño, no escribir pruebas, no documentar, integrar por parche— son las mismas que encarecen cada cambio posterior. El ahorro se concentra en el primer trimestre y el sobrecoste se reparte en los años siguientes.
Cuatro cosas: propiedad del código, la documentación y la propiedad intelectual; contratos de integración versionados y documentados; corrección de defectos sin coste; y un plan de transición que permita que otro equipo se haga cargo sin depender del proveedor original.
En la mayoría de los casos sí, siempre que exista un diagnóstico previo. Auditar, refactorizar y modernizar por dominios permite reducir los costes de mantenimiento de forma significativa —hasta un 60% en proyectos que hemos ejecutado— manteniendo la operación en marcha, algo que una reescritura completa no permite.
¿Sabes cuánto te va a costar tu software dentro de tres años? Nuestra auditoría técnica entrega por escrito el estado de arquitectura, código, deuda y seguridad, con precio cerrado y en 10 días hábiles. Es la forma más barata de descubrir un problema caro. Pide tu auditoría → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
