Deuda técnica: la guía del fundador no técnico (4 tipos, diagnóstico)
Un miércoles de noviembre, en una oficina en Madrid, el fundador de una fintech en Series A oyó la misma frase por tercera vez en el mes: “necesitamos parar de construir features durante seis semanas y pagar la deuda técnica”. Era la primera vez que entendía que ese era un problema suyo, no de su tech lead. Los inversores le pedían un plan de producto para los próximos doce meses. El equipo de ingeniería pedía seis semanas paradas. Los dos pedidos chocaban, y la decisión era suya.
Ese es el momento exacto en el que la mayoría de fundadores no técnicos descubren qué es la deuda técnica. Demasiado tarde para evitarla, demasiado temprano para entender lo que se propone.
Qué es la deuda técnica, en lenguaje de fundador
Deuda técnica es toda elección de ingeniería que cambia calidad futura por velocidad hoy. Escribes el código más rápido ahora, sabiendo que vas a pagar la diferencia después: en mantenimiento, en bugs, en refactor, o en un ingeniero nuevo que tarda tres semanas en entender qué pasa.
El término lo acuñó Ward Cunningham en los años 90, y la metáfora es precisa. Igual que la deuda financiera, la deuda técnica genera intereses. Cada release hecho sobre una base mala añade un poco más de fricción, un poco más de tiempo, un poco más de riesgo. Si nunca pagas, los intereses se comen la velocidad del equipo. Si pagas siempre, estás dejando velocidad sobre la mesa que podría haber sido invertida en producto.
Lo que importa para el fundador no es la definición académica. Es entender que la deuda técnica nunca es una sorpresa creada por el equipo. Es el subproducto de decisiones que se tomaron, explícita o implícitamente, para que pudieras hacer la demo del inversor, cerrar el primer cliente, lanzar el piloto antes del competidor. La deuda no apareció por incompetencia. Apareció porque alguien priorizó velocidad. Probablemente tú.
Por qué esto se vuelve problema tuyo, no del CTO
Tres cosas cambian cuando la deuda técnica deja de ser una conversación de ingeniería y se vuelve una conversación de empresa.
La primera es el ritmo de release. Equipos con deuda pesada empiezan a sentir que cada feature tarda más. Lo que solía salir en dos semanas empieza a salir en cuatro. No porque los ingenieros empeoraron. Porque cada vez más de su tiempo se gasta esquivando trampas que el código antiguo dejó.
La segunda es el riesgo de contratación. Equipos con deuda pesada son difíciles de ampliar. Cuando quieres duplicar el squad para acelerar, descubres que el ingeniero nuevo necesita seis semanas para poder abrir un pull request sin romper tres cosas. Tu tasa de onboarding se desploma. Crees que contratar está caro; en realidad está caro el ramp-up.
La tercera es el riesgo de due diligence. En una ronda Series A o en una adquisición, el inversor contrata una consultoría de due diligence técnica. Pasa cuatro días dentro de tu repositorio, habla con el equipo, y produce un documento que dice si la base de código soporta los próximos veinticuatro meses o no. Si la deuda está demasiado alta, el inversor puede pedir descuento en la valoración. Puede pedir hitos de “pago de deuda” antes del siguiente tramo. En casos raros, puede retirarse.
Ninguno de esos tres efectos es técnico. Todos son de negocio. Y todos le llegan al fundador antes o después.
Los cuatro tipos de deuda técnica que importan
Martin Fowler, uno de los investigadores que más ha escrito sobre el tema, creó una matriz de dos ejes que separa las cuatro situaciones en que aparece deuda técnica. Para el fundador, la matriz es útil porque responde una pregunta única e importante: ¿mi equipo hace esto a propósito, o lo hace por descuido? Esa pregunta separa la deuda “estratégica” (que puedes estar contento de cargar) de la deuda “peligrosa” (que te está costando dinero en silencio).
1. Deliberada y prudente: “sabemos lo que estamos haciendo, y vamos a pagar después”
El equipo eligió, consciente, escribir código más simple y rápido porque necesitaba llegar a algún lugar primero. Tal vez la demo del TechCrunch, tal vez el piloto con un cliente clave, tal vez el release antes de las vacaciones. Documentaron la elección. Saben dónde está el atajo. Tienen una fecha, aunque aproximada, para volver y hacerlo bien.
Esta es la deuda que quieres en la empresa los primeros dieciocho meses. Sin ella, no llegas al PMF a tiempo.
2. Deliberada e imprudente: “sabemos lo que estamos haciendo, y nunca vamos a pagar”
El equipo eligió el atajo, sabe que es atajo, y está convencido de que da tiempo para romper tres cosas antes del release. Muchas veces esta deuda viene del propio fundador: “necesito esto para el viernes, arréglatelas”. El equipo avisa que es mala idea. Tú dices “después lo arreglamos”. No se arregla.
Es el tipo más común y más caro. No porque sea el peor técnicamente, sino porque el “después” nunca llega. Y porque se acumula en silencio: no ves la deuda en el balance. Solo ves la feature terminada.
3. Accidental y prudente: “ahora sabemos cómo deberíamos haberlo hecho”
El equipo hizo lo mejor que sabía en su momento, con la información que tenía. Aprendió más sobre el problema, sobre la arquitectura, sobre los usuarios, y hoy lo haría diferente. No es descuido, es la curva de aprendizaje natural de cualquier producto nuevo.
Esta deuda la vas a tener, siempre. La pregunta correcta para este tipo no es “¿cómo la evito?”. Es “¿cuándo vuelvo y la rehago?”. Y la respuesta honesta es: cuando la feature que está encima de la base equivocada empiece a costar más evolucionarla que reescribirla.
4. Accidental e imprudente: “ni siquiera sabemos que esto es deuda”
El equipo no sabe que eligió un camino malo. No documentó nada. Va a descubrir el problema la próxima vez que necesite tocar ese pedazo del código, y la próxima persona que lo toque va a sufrir sin entender por qué. Es la categoría más peligrosa porque es invisible. Solo te das cuenta cuando alguien renuncia y el conocimiento se va con la persona, o cuando el nuevo dev sénior abre el repositorio y respira hondo.
La diferencia entre los tipos 2 y 4 es donde vive el trabajo del fundador. El tipo 2 puedes rastrearlo hablando con el equipo. El tipo 4 necesitas una due diligence interna para descubrirlo, y casi ningún fundador la hace antes de que llegue la factura.
El diagnóstico de cuatro preguntas
No necesitas fingir profundidad técnica para descubrir cuánta deuda carga tu producto. Necesitas cuatro preguntas, veinte minutos con cada ingeniero, y el coraje de escuchar las respuestas sin defenderte.
Pregunta 1: “¿Cuál es el pedazo del código que nadie quiere tocar?”
Toda base de código tiene uno. Puede ser el módulo de pagos, el sistema de autenticación, el motor de cálculo de comisiones. Lo que estás buscando es un nombre propio. Si tres ingenieros responden lo mismo, ese es el corazón de tu deuda accidental imprudente.
Pregunta 2: “¿Cuántas veces en el último sprint hicimos un workaround porque la solución correcta tardaría demasiado?”
Esta pregunta detecta deuda deliberada, la del tipo 2. La respuesta sana es “una, y abrimos un ticket para volver”. La respuesta de alerta es “tres o cuatro, sin tickets”. Workaround sin ticket es deuda que no se va a pagar.
Pregunta 3: “Si quisiéramos duplicar el equipo mañana, ¿cuántas semanas hasta que el nuevo ingeniero abra su primer PR?”
Equipos sanos responden una o dos semanas. Equipos con deuda alta responden entre cuatro y ocho. Por encima de eso, tu deuda ya no es un problema de producto. Es un problema de escala del equipo.
Pregunta 4: “Si perdiéramos al ingeniero X, ¿qué pedazo del producto quedaría huérfano?”
Esta pregunta es el cruce entre deuda técnica y bus factor. El conocimiento no documentado es deuda accidental imprudente, y desaparece con la persona. Si la respuesta es “la mitad”, tienes dos problemas, no uno.
Las cuatro preguntas sumadas dan un mapa razonable del estado de tu base de código. No es una due diligence técnica formal. Pero alcanza para que decidas, con la cabeza fría, si el equipo necesita seis semanas paradas para pagar deuda o si está pidiendo seis semanas paradas para reescribir algo que funciona.
Cuándo pagar, cuándo cargar, cuándo ignorar
No toda deuda debe pagarse. Ese es el error que la mayoría de los fundadores comete en la dirección opuesta: después de entender el concepto, se ponen ansiosos por “dejar la deuda en cero”. No funciona así.
Carga la deuda que está estable. Si un pedazo del código es desordenado pero nadie ha necesitado tocarlo en seis meses, no lo toques. La regla es simple: la deuda solo te cuesta si estás pagando intereses. El código que nadie abre no tiene intereses.
Paga la deuda que está en el camino del roadmap. Si el próximo trimestre va a exigir cambios en el módulo X, y el módulo X es un desastre, vale la pena pagar la deuda antes. Ibas a pagar por el refactor de cualquier manera, incrustado en la feature, sin visibilidad.
Reescribe (no pagues) la deuda que está bloqueando crecimiento. Si el sistema de autenticación no soporta más de mil usuarios simultáneos, o si el motor de cálculo tarda tres horas en correr con cinco mil clientes, eso no es deuda. Es arquitectura que necesita ser sustituida. No estás pagando intereses. Estás en un callejón sin salida. La conversación ahí se vuelve reescritura de software, que es una decisión distinta y mucho más cara.
La heurística que usamos cuando trabajamos con fundadores no técnicos: mira la deuda por el lado del roadmap, no por el lado del código. ¿Qué se va a tocar en los próximos noventa días, y está difícil de tocar? Eso es lo que vale la pena pagar. El resto es cosmético.
La conversación que tiene que pasar con el equipo
La conversación equivocada empieza así: “¿pueden darme una estimación de cuánta deuda técnica tenemos?”. No vas a conseguir respuesta útil. Nadie sabe cuantificar deuda en horas o en euros con precisión. El equipo va a tirar un número, tú vas a dudar del número, y la conversación no va a ningún lado.
La conversación correcta empieza distinto. Toma el roadmap de los próximos noventa días. Para cada item, pregunta: “¿este item toca algún pedazo donde tenemos deuda que valga la pena resolver antes?”. Si la respuesta es sí para tres o cuatro items en el mismo módulo, ese es el pedazo donde quieres invertir un sprint de refactor antes de seguir.
Esta conversación funciona porque amarra la deuda a lo que se está construyendo. No es “paren todo y arreglen el pasado”. Es “vamos a invertir una semana ahora para que el próximo trimestre avance más rápido”. Los inversores entienden ese lenguaje. Los cofundadores lo entienden. Lo puedes defender en el board.
Y tiene un efecto secundario: obliga al equipo a señalar deuda específica, no deuda genérica. “Tenemos deuda en el módulo de pagos que va a pesar en los próximos tres proyectos” es una frase accionable. “Tenemos mucha deuda técnica” no lo es.
Qué cambia cuando externalizas el desarrollo
Si no tienes un equipo interno, y tu producto lo está construyendo una software house o un partner de desarrollo, la dinámica de la deuda cambia en dos puntos importantes.
El primero: la deuda accidental imprudente es más difícil de detectar. El equipo externo no está en tu Slack todos los días, así que la pregunta “¿cuál es el pedazo del código que nadie quiere tocar?” necesita hacerse con más frecuencia, y la respuesta tiene que venir con capturas, commits, ejemplos. Confía en datos, no en sensaciones.
El segundo: la deuda deliberada prudente es más fácil de cargar, porque un partner experimentado ya te va a decir, antes de cada release, qué se está dejando atrás y por qué. Los buenos partners lo hacen por hábito. Los malos partners entregan el producto y desaparecen. La diferencia entre los dos aparece exactamente en esa transparencia: ¿sabes o no sabes dónde está la deuda cuando sale el release?
La regla que aplicamos cuando construimos software para fundadores no técnicos es simple: toda decisión de tomar deuda deliberada prudente tiene que registrarse en una frase en el PR, y tiene que aparecer en el documento mensual de estado. Si no tienes eso, estás a oscuras. No es que el partner tenga mala intención; es que el proceso está mal diseñado.
Cuando la deuda técnica se vuelve un problema de coste de mantenimiento
El coste de mantenimiento mensual de tu producto es, en parte, el pago de los intereses de la deuda que tomaste. Si tu equipo gasta sesenta por ciento del tiempo “arreglando cosas” y cuarenta por ciento “construyendo cosas”, la mayor parte de ese sesenta por ciento son intereses, no bugs.
Equipos sanos están cerca de ochenta-veinte (ochenta construyendo, veinte arreglando). Equipos con deuda pesada llegan invertidos, sesenta-cuarenta. Equipos en estado crítico llegan a veinte-ochenta, y a esa altura ya no estás construyendo producto, estás manteniendo un esqueleto vivo mientras tus competidores lanzan features.
El ratio es una de las cosas más fáciles de medir y una de las más subestimadas. Si no sabes cuál es el tuyo, pregúntale al equipo. Lo saben. Probablemente lo saben desde hace meses.
Preguntas frecuentes
¿Qué es la deuda técnica?
Es toda elección de ingeniería que cambia calidad futura por velocidad hoy. Como una deuda financiera, genera intereses: cada release hecho sobre una base mala añade un poco más de tiempo, fricción y riesgo. Puede ser deliberada (elegiste el atajo) o accidental (el equipo aprendió después que podría haberlo hecho diferente).
¿Cuál es la diferencia entre débito técnico y deuda técnica?
Ninguna. “Débito técnico” y “deuda técnica” son dos traducciones del mismo término en inglés (technical debt) y se usan como sinónimos en el mercado hispanohablante. Si un ingeniero habla de débito y otro de deuda, están hablando de lo mismo.
¿Cuáles son los tipos de deuda técnica?
La matriz más usada es la de Martin Fowler, que cruza dos ejes: deliberada/accidental y prudente/imprudente. Eso da cuatro tipos: deliberada y prudente (elegiste el atajo y vas a pagar), deliberada e imprudente (elegiste el atajo y no vas a pagar), accidental y prudente (aprendiste después y rehaces cuando vale), accidental e imprudente (el equipo ni sabe que existe deuda ahí). Los tipos 2 y 4 son los que más lastiman al fundador no técnico.
¿Cuánto tiempo lleva pagar deuda técnica?
No hay respuesta única. Depende del tamaño de la base, del tipo de deuda y de cuánto del roadmap futuro la atraviesa. Una regla práctica que usamos: si un área específica está bloqueando tres o cuatro items de los próximos noventa días, invierte una a dos semanas de sprint enfocado en ella antes de seguir. Los intentos de “pagar toda la deuda” en un esfuerzo único raramente funcionan: el equipo pierde meses y el backlog de producto se congela.
¿Cómo se mide la deuda técnica?
No se mide con precisión. Puedes aproximarla con el diagnóstico de cuatro preguntas de arriba, con el ratio construir-versus-arreglar (cuánto del tiempo del equipo se va en arreglar en lugar de construir), y con el tiempo de ramp-up de un ingeniero nuevo. Ninguno de estos es exacto, pero juntos te dicen si tu deuda está en territorio sano o peligroso.
La mayoría de fundadores no técnicos aprenden el concepto de deuda técnica en el peor momento posible: cuando el equipo pide parar, cuando el inversor pide acelerar, o cuando una due diligence señala un problema que nadie vio venir. El fundador que decide bien en ese momento no es el que entiende más de código. Es el que sabe leer la deuda como una decisión de negocio y hacerle al equipo la pregunta correcta: ¿qué de los próximos noventa días está más difícil porque no hemos pagado todavía?
Ese fundador no necesita ser técnico. Necesita ser claro.