Deuda técnica: cómo detectarla antes de que te cueste una migración completa

Deuda técnica no es un término de moda — es literal: cada atajo que tomas hoy para entregar más rápido se paga después, con intereses, en forma de horas de desarrollo que no deberían existir. El problema es que casi nadie la detecta hasta que ya es cara: cuando agregar una feature simple toma semanas, o cuando el único desarrollador que entendía el sistema ya no responde el teléfono.

El costo real, en la práctica

La analogía financiera no es solo retórica. Un atajo — saltarse una prueba automatizada, duplicar lógica en vez de extraerla, acoplar dos módulos que deberían ser independientes — no cuesta nada visible el día que se toma. El costo aparece cada vez que alguien tiene que trabajar alrededor de esa decisión: entender por qué el código hace algo raro, evitar romper una dependencia oculta, o directamente reescribir esa parte porque nadie se atreve a tocarla. Cuanto más tiempo pasa entre el atajo y el momento en que alguien lo paga, más caro resulta corregirlo, porque para entonces ya hay más código construido encima que asume que ese atajo es 'normal'.

No toda la deuda técnica es igual

Es útil separar la deuda técnica en dos ejes: si fue una decisión deliberada o inadvertida, y si fue una decisión prudente o imprudente. Un equipo que decide conscientemente lanzar sin cierta optimización porque necesita validar el producto primero está tomando deuda prudente y deliberada — es una apuesta de negocio razonable, siempre que se documente y se planee pagar. El problema real es la deuda imprudente e inadvertida: código escrito sin entender bien el problema, copiado de un tutorial sin adaptarlo, o construido bajo tanta presión que nadie pudo pensar en las consecuencias. Esa es la que se acumula sin que nadie la decida a propósito, y por eso es la más peligrosa — no aparece en ninguna conversación hasta que ya es un problema serio.

De dónde viene, en el mercado colombiano específicamente

• Builders No-Code usados para lo que no fueron diseñados: lógica de negocio compleja empujada dentro de un editor visual que no versiona código ni corre tests.
• Freelancers que entregan y desaparecen — sin documentación, sin handoff, sin que nadie más entienda las decisiones que tomaron.
• Presión de negocio: 'lánzalo ya, lo arreglamos después' — y el 'después' nunca llega porque el sistema sigue vendiendo, aunque mal.
• Falta de pruebas automatizadas, así que cada cambio nuevo tiene el riesgo real de romper algo que ya funcionaba.

El caso de los builders No-Code merece un comentario aparte porque es particularmente traicionero: en la demo se ve rápido y funcional, y para un flujo simple (una landing con un formulario, un catálogo estático) es una herramienta perfectamente razonable. El problema empieza cuando el negocio crece y la lógica también — descuentos condicionales, integraciones con pasarelas de pago, reglas de inventario — y esa complejidad se sigue empujando dentro del mismo editor visual porque 'ya está ahí'. Llega un punto en que el sistema tiene reglas de negocio críticas atrapadas en una interfaz que no se puede versionar en Git, no corre pruebas automatizadas, y solo una persona en la empresa sabe navegar. Eso no es una herramienta mala — es una herramienta usada más allá de su propósito.

Señales de que ya tienes deuda técnica

• Una función que antes tomaba días ahora toma semanas, sin que el alcance haya crecido.
• Nadie en el equipo actual puede explicar por qué el sistema hace algo de una forma específica.
• Cada despliegue nuevo genera ansiedad, no confianza.
• El único documento técnico que existe es un chat de WhatsApp con el freelancer anterior.
• Agregar un campo nuevo a un formulario requiere tocar código en cinco lugares distintos.

Cuándo SÍ tiene sentido un builder No-Code

Vale la pena ser justos con la herramienta: para un prototipo que valida una idea de negocio antes de invertir en desarrollo a la medida, para una landing con formulario, o para un flujo interno simple que no cambia con frecuencia, un builder No-Code es una decisión perfectamente razonable — más rápida y más barata que escribir código propio para algo que quizás ni siquiera sobreviva la validación de mercado. El problema nunca es la herramienta en sí, es no tener un plan de cuándo migrar a código propio una vez que la lógica de negocio deja de ser simple. Esa decisión — 'a partir de aquí, esto ya necesita ser código versionado' — debería tomarse a propósito, no descubrirse seis meses tarde cuando ya es doloroso.

Cómo medirla sin herramientas complejas

No hace falta un dashboard sofisticado para empezar a ver el problema — tres señales simples, seguidas en el tiempo, ya dan una buena idea. Primero, el tiempo que le toma a un desarrollador nuevo hacer su primer commit útil: si en un sistema sano toma dos o tres días y en el tuyo toma tres semanas, ahí hay una señal clara de que el conocimiento no está en el código sino en la cabeza de alguien. Segundo, la duración de las revisiones de código (pull requests): si cada vez toman más tiempo y generan más discusión sobre 'qué hace esto realmente', el sistema se está volviendo más difícil de razonar. Tercero, y el más simple de todos: cuántas veces por sprint el equipo dice la frase 'no toquemos eso, por si acaso'. Esa frase, repetida, es la definición operativa de deuda técnica.

Un cuarto indicador, menos evidente pero igual de útil, es la proporción de tiempo del sprint que se va en 'entender' contra 'construir'. Es normal y sano que investigar cómo funciona algo tome parte del tiempo de cualquier tarea — pero cuando un equipo empieza a pasar más tiempo leyendo código viejo para entender qué hace que escribiendo la funcionalidad nueva en sí, esa proporción invertida es una de las señales más confiables de que el sistema acumuló más complejidad de la que el equipo actual puede sostener cómodamente.

Cómo se evita, no cómo se cura

La deuda técnica no se 'arregla' con una sola sesión de refactor — se previene con decisiones de arquitectura desde el inicio: código propio (no atado a un builder que controla otra empresa), documentación técnica real entregada junto con el software (no como favor), y una separación clara entre lógica de negocio y capa de presentación para que un cambio en una no obligue a tocar la otra.

En la práctica, esto se sostiene con hábitos concretos, no solo con buenas intenciones: revisión de código obligatoria antes de integrar cualquier cambio (aunque sea entre dos personas), un registro breve de decisiones de arquitectura importantes — qué se decidió y por qué, no un documento de veinte páginas, solo lo suficiente para que alguien nuevo entienda el razonamiento seis meses después — y pruebas automatizadas al menos sobre la lógica de negocio crítica, aunque no se llegue a una cobertura total desde el primer día.

El rol de las pruebas automatizadas en frenar deuda nueva

Una suite de pruebas automatizadas no elimina la deuda técnica que ya existe, pero cumple un rol distinto y valioso: frena la deuda nueva. Sin pruebas, cada cambio es un salto de fe — nadie sabe con certeza si algo se rompió hasta que un usuario lo reporta. Con pruebas sobre los flujos críticos del negocio (procesar un pago, calcular un precio, generar una factura), el equipo puede refactorizar con confianza real, porque hay una forma objetiva de saber si el comportamiento cambió o no. Esto es lo que hace posible pagar deuda técnica existente sin miedo constante a romper algo que ya funcionaba — y es la razón por la que un sistema sin ninguna prueba automatizada tiende a acumular deuda cada vez más rápido con el tiempo, no a un ritmo constante.

La migración incremental en la práctica

Si ya estás en el punto de 'nadie entiende esto', la migración completa suele ser más barata a largo plazo que seguir parchando — pero eso no significa detener el negocio dos meses para reescribir todo. Se puede hacer de forma incremental, módulo por módulo, si la arquitectura nueva se diseña para convivir con la vieja mientras se reemplaza: el módulo más aislado y menos riesgoso se migra primero, se valida en producción con tráfico real, y solo después se avanza al siguiente. Es más lento que un 'Big Bang', pero es la diferencia entre una migración que se puede pausar sin dejar el negocio a medio camino y una apuesta de todo o nada.

El error más común en esta fase no es técnico, es de expectativa: tratar la migración incremental como un proyecto con fecha de cierre fija, en vez de como un proceso continuo que se prioriza junto con el resto del roadmap. Cuando el negocio entiende que cada módulo migrado reduce el riesgo acumulado y libera capacidad del equipo para construir features nuevas más rápido, es más fácil sostener el esfuerzo en el tiempo — en vez de abandonarlo a mitad de camino la primera vez que aparece una prioridad de negocio urgente, que es exactamente cómo un sistema termina con la mitad de su arquitectura modernizada y la otra mitad congelada en el tiempo.