Un fundador con el que trabajamos eligió entre un desarrollo de 15.000 $ y otro de 65.000 $. Eligió el de 15.000 y, por cualquier criterio razonable, acertó: consiguió un producto funcionando, usuarios reales y una ronda seed. Dieciocho meses después gastó 210.000 $ en sustituirlo.

No es una historia sobre un mal proveedor. El producto hizo aquello por lo que se pagó. El error fue confundir la factura con el coste, cuando la factura es solo la entrada.

La deuda técnica cobra cinco impuestos

La deuda no es que el código sea feo. Es que cada decisión futura cuesta más de lo que debería. Aparece en cinco sitios, y los cinco son medibles.

• El impuesto de velocidad. Funciones de tres días que tardan nueve, porque nada está probado y cada cambio rompe algo sin relación. En un equipo de cuatro, ir el doble de lento cuesta unos 30.000 $ al mes en salarios comprando la mitad del resultado.
• El impuesto de incidencias. Caídas, correcciones de datos, hilos de soporte airados. No solo horas de ingeniería: clientes que se van sin explicar por qué.
• El impuesto de contratación. Los buenos ingenieros entrevistan tu código tanto como tú los entrevistas a ellos. Un repositorio sin pruebas ni documentación te cuesta los candidatos que más querías, o un 15–20% más para convencerlos.
• El impuesto comercial. Los compradores corporativos envían cuestionarios de seguridad. Los inversores envían revisores técnicos. Cada pregunta sin respuesta es un descuento que no pensabas dar.
• El impuesto de reescritura. Al final, la única vía adelante es hacia atrás. Una reescritura siempre cuesta más que el desarrollo original, porque además hay que replicar comportamientos que nadie documentó manteniendo vivo el sistema antiguo.

La aritmética del segundo año

Volvamos al desarrollo de 15.000 $. El segundo año fue así: dos ingenieros a rendimiento reducido durante ocho meses, un contrato corporativo perdido en una revisión de seguridad, tres meses de sistemas en paralelo durante la sustitución y una reconstrucción de 210.000 $. Incluso sin contar el contrato perdido, aquella decisión costó más de 300.000 $. La opción de 65.000 habría sido la barata.

Esto no es un argumento para gastar más. Es un argumento para saber en qué línea estás.

Qué separa realmente a las dos opciones

La diferencia nunca estuvo en el número de funciones. Estuvo en esto:

• Pruebas automatizadas alrededor de las partes que mueven dinero o datos personales.
• Un despliegue que cualquier ingeniero puede ejecutar, en vez de una persona que conoce el ritual.
• Control de acceso diseñado una vez, en la capa de datos, en lugar de comprobado a mano en cada pantalla.
• Decisiones escritas —por qué esta base de datos, por qué esta cola, por qué este compromiso— para que el siguiente equipo no tenga que adivinar.
• Dependencias elegidas por mantenimiento, no por novedad.

Nada de esto es vistoso ni se ve en una demo. Por eso mismo es lo primero que se recorta en una propuesta que compite por precio.

Cómo detectar el desarrollo barato antes de firmar

1. Pregunta qué porcentaje del presupuesto son pruebas. Si la respuesta es cero o "probamos manualmente", estás comprando el desarrollo barato.
2. Pide ver un repositorio que entregaran hace dieciocho meses. No una demo: un repositorio.
3. Pregunta quién está de guardia tras el lanzamiento y qué pasa a las 2 de la madrugada. El silencio aquí sale caro después.
4. Pregunta cómo arrancaría el proyecto un ingeniero nuevo en local y cuánto tarda. Más de una hora anticipa cómo será el mantenimiento.
5. Pregunta qué se negarían a construir con ese presupuesto. Quien no dice que no a nada ya ha decidido dejarte a ti las partes difíciles.

No eliges si pagas por la calidad. Solo eliges si la pagas ahora, a coste, o después, con prima y con plazo encima.

Cada sistema que construimos nace listo para auditoría: probado, documentado y entregado con la propiedad intelectual completa el primer día. Si has heredado algo que no lo es, una auditoría técnica breve te dirá cuáles de los cinco impuestos ya estás pagando.