El comprador descubre la deuda técnica después de firmar. En la due diligence el equipo lee ingresos, margen, churn y cohortes y deja el código para después. Para entonces el precio ya está fijado. El vendedor llega a esa misma mesa sin ningún número: el sistema está en línea, los tests pasan y nadie sumó el costo de mantener eso en pie.
Las preguntas que quedan fuera de la lista
El comprador pregunta por LTV, CAC, ingresos recurrentes y tasa de renovación. Las preguntas de ingeniería no entran: tiempo del commit a producción, bugs por mes, cuántas personas modifican el núcleo del sistema, cuándo actualizaron por última vez las dependencias centrales.
Todas esas respuestas existen y cuestan una tarde. Git, el pipeline y el repositorio de issues ya guardan el dato. Alguien tiene que abrirlos.
Cinco preguntas de ingeniería para la due diligence
- Tiempo de build y deploy. ¿Cuánto pasa del commit al ambiente de producción? Horas indican un pipeline sano. Días indican cola de aprobación, prueba manual y una persona en la ruta crítica de cada release.
- Bugs en producción. ¿Cuántos incidentes por mes en los últimos 12 meses y hacia dónde va la línea? Los sistemas maduros mantienen una tasa baja y estable. Una tasa al alza denuncia deterioro.
- Concentración de conocimiento. ¿Cuántas personas modifican el núcleo sin pedir ayuda? Menos de tres, y el comprador hereda un riesgo de salida de personas clave que aparece en la primera ausencia.
- Edad de las dependencias. ¿Cuándo se actualizaron por última vez los paquetes centrales? Un paquete detenido dos años carga un CVE conocido y bloquea una actualización de lenguaje durante tres sprints.
- Documentación de arquitectura. ¿Existe un diagrama con fecha del año pasado? Una página de Confluence de 2022 describe el sistema de 2022.
Nicole Forsgren, Jez Humble y Gene Kim midieron en Accelerate (IT Revolution, 2018) el vínculo entre el desempeño de entrega y el desempeño del negocio. Esos mismos números le dicen al comprador cuánto consume el mantenimiento por trimestre.
Convertir hallazgos en un número
Suma tres estimaciones. Estabilizar: corregir vulnerabilidades, actualizar dependencias, cubrir tests faltantes. Escalar: qué cambia para que el sistema soporte el crecimiento proyectado. Ignorar: qué pasa si no cambia nada, con indisponibilidad, pérdida de datos y exposición.
El total entra en la mesa de negociación. En sistemas legados de más de diez años, el resultado suele caer entre el 15% y el 40% del valor de adquisición.
Steve McConnell trata la estimación de esfuerzo en Software Estimation (Microsoft Press, 2006) y defiende un rango con escenario optimista y pesimista en lugar de un número cerrado. El rango absorbe la discusión que empieza cuando arranca el trabajo; un número solo se vuelve conflicto.
Tres formas de cerrar la brecha
Ajuste de precio. El comprador descuenta del valor de adquisición el costo estimado de la deuda. Es la vía más simple y se sostiene cuando el número viene de evidencia verificable.
Obligaciones posteriores al cierre. El vendedor asume items específicos con plazo y multa. Funciona cuando el equipo que generó la deuda sigue en el lugar después del cierre.
Escrow. Parte del valor queda retenida hasta que los items acordados lleguen a un nivel aceptable. Requiere más estructura y cubre mejor la deuda que depende de trabajo interno.
El vendedor que mide antes de salir al mercado
Una auditoría técnica antes de poner la empresa a la venta pone el problema sobre la mesa mientras todavía da tiempo de arreglarlo. El vendedor corrige lo barato, pone precio a lo caro y llega a la due diligence con el número en la mano. El comprador encuentra un equipo que ya se miró por dentro y pide un descuento menor por incertidumbre.
