El verdadero coste de la deuda técnica: cómo acabó con tres startups financiadas
Tres startups bien financiadas y con productos excelentes cerraron, no por tener malas ideas, sino porque la deuda técnica les impedía lanzar sus productos, contratar personal o crecer. A continuación, explicamos qué falló y cómo evitarlo.
La deuda técnica no es un problema de los desarrolladores. Es un problema empresarial.
Como fundador o director técnico, seguro que has oído a los ingenieros quejarse de la «deuda técnica». Suena abstracto, como algo que ralentiza a los desarrolladores pero que en realidad no afecta al negocio. Hasta que lo hace.
La deuda técnica es la diferencia entre el código que tienes y el código que necesitas. Al igual que la deuda financiera, se acumula. Un atajo que hoy te ahorra dos semanas te costará dos meses el año que viene. A continuación, te presentamos tres empresas reales que se dieron cuenta de esto demasiado tarde.
Caso 1: La startup de la ronda de financiación Serie B que no fue capaz de lanzar una función en seis meses
Una empresa de SaaS B2B recaudó 18 millones de dólares en una ronda de financiación de serie B. Su producto tenía un sólido ajuste producto-mercado. Sin embargo, tras dos años de seguir la filosofía de «avanzar rápido y romper cosas», añadir cualquier nueva función requería modificar más de 15 archivos, cada cambio provocaba algún otro fallo y las implementaciones tardaban tres horas, incluyendo las pruebas manuales.
Las cifras: antes de la deuda, lanzaban 4 funciones al mes; después de la deuda, 0,5 funciones al mes. Su competidor (que invirtió en arquitectura desde el principio) lanzaba 6 funciones al mes. En 18 meses, el competidor se había hecho con el mercado.
No quebramos por tener un mal producto. Quebramos porque no fuimos capaces de desarrollar el producto con la suficiente rapidez. Cada función nos llevaba cuatro veces más tiempo que a nuestra competencia.
— CTO de Anonymous, análisis posterior
Caso 2: La plataforma de comercio electrónico que perdió el Black Friday
Una startup de comercio electrónico tenía un backend monolítico sin almacenamiento en caché ni pruebas de carga, y con consultas a la base de datos que funcionaban bien con 1 000 usuarios, pero que se colapsaban al llegar a los 50 000. Llevaban un año sabiendo del problema. «Lo arreglaremos después de lanzar la próxima función» era la decisión que tomaban una y otra vez.
Llegó el Black Friday. La página web estuvo inactiva durante nueve horas. Se calcula que perdieron 2,3 millones de dólares en ingresos y la confianza de 40 000 clientes que nunca volvieron. La mentalidad de «ya lo arreglaremos más tarde» les salió más cara que reconstruir todo el sistema.
Caso 3: La empresa fintech que no superó una auditoría de seguridad
Una startup fintech necesitaba cumplir con la norma SOC 2 para conseguir clientes empresariales. La auditoría reveló lo siguiente: claves API codificadas directamente en el código fuente, ausencia de cifrado en reposo, contraseñas de usuario hashadas con MD5 y falta de registros de auditoría. Para solucionar estos problemas fue necesario reescribir el 60 % del backend. La corrección, que duró seis meses, agotó los recursos financieros que les quedaban.
Los acuerdos empresariales con los que contaban nunca se cerraron porque no se pudo completar la auditoría a tiempo.
Cómo medir la deuda técnica (para quienes no son ingenieros)
No hace falta saber leer código para detectar la deuda técnica. Plantea estas preguntas a tu equipo de ingeniería:
| Pregunta | Respuesta saludable | Bandera roja |
|---|---|---|
| ¿Cuánto tiempo se tarda en implementar un cambio de una sola línea? | Menos de 30 minutos | Más de 2 horas |
| ¿Qué porcentaje del sprint se dedica a la resolución de errores frente a la implementación de nuevas funciones? | Menos del 20 % | Más del 40 % |
| ¿Puede un desarrollador novato lanzarse al mercado desde el primer día? | Sí, con ayuda | La incorporación tarda entre 2 y 4 semanas |
| ¿Cuántas cosas se estropean cuando se cambia una sola cosa? | De vez en cuando, hacemos pruebas | Realizamos pruebas manuales constantemente |
| ¿Cuándo fue la última vez que actualizaste una dependencia? | Mensual | Nos da miedo tocarlo |
La regla del 20 %: cómo evitar que las deudas te ahoguen
Los equipos de ingeniería más exitosos con los que hemos trabajado siguen la regla del 20 %: dedican el 20 % de cada sprint a reducir la deuda técnica. Ni el 100 % (eso paraliza el negocio). Ni el 0 % (eso garantiza problemas en el futuro). El veinte por ciento.
En un sprint de dos semanas con cinco desarrolladores, eso supone dos días-desarrollador dedicados a: actualizar dependencias, escribir pruebas para el código sin probar, refactorizar el módulo más desordenado, mejorar los tiempos de implementación o documentar los conocimientos implícitos.
Esto no es un gasto. Es una inversión. Las empresas que superan la ronda de financiación de serie B son aquellas que consideran la calidad del código como un indicador empresarial, y no como una mera preferencia de ingeniería.
La cuestión no es si puedes permitirte invertir en la calidad del código. La cuestión es si puedes permitirte no hacerlo. La deuda técnica se acumula a un interés del 100 %.
— alokknight Ingeniería