Valuations alineados, términos avanzados, kickoff de integración agendado. Entonces el informe de due diligence técnica apunta a un monolito sin tests, tres ingenieros con el conocimiento de sistemas críticos, dependencias con CVEs abiertos y una arquitectura que no habla con el stack del adquirente.
Los revisores encuentran esa combinación más seguido de lo que el equipo financiero imagina. El precio aparece como ajuste de valuation, obligación post-cierre o una negociación que se cae.
Qué mide la due diligence técnica
La due diligence técnica evalúa el estado real de los activos tecnológicos antes de que cierre la transacción: una adquisición, una ronda de serie A en adelante, una fusión.
El equipo revisor no lee código línea por línea. Mide la salud del sistema, la práctica de ingeniería, los riesgos operativos y el margen del producto para crecer junto al plan de negocio. Brad Feld y Jason Mendelson recorren la secuencia de diligence y term sheet en Venture Deals (Wiley, 2019).
El informe sirve a los dos lados. El comprador ve lo que está comprando. El vendedor gana espacio para explicar decisiones que los números dejan afuera.
Seis dimensiones en la evaluación
1. Arquitectura y escalabilidad
El revisor compara la arquitectura con la curva de 18 meses del plan de negocio, busca cuellos de botella que ya aparecen en carga y pregunta quién es el dueño de la deuda de arquitectura.
2. Código y tests
El informe mide la cobertura de tests automatizados, marca las áreas que nadie modifica sin romper vecinos y trae la tasa mensual de bugs en producción. Michael Feathers muestra en Working Effectively with Legacy Code (Prentice Hall, 2004) que el código sin teste se vuelve código que nadie toca.
3. Seguridad
La búsqueda cubre vulnerabilidades críticas abiertas, secretos versionados, dependencias con CVE publicado y la fecha del último test de penetración. La prioridad viene del OWASP Top 10 (2021).
4. Infraestructura y operaciones
Las operaciones aportan deploys automatizados y trazables, tiempo medio de recuperación de incidentes y monitoreo que dispara alertas. El libro de Google SRE (Beyer, Jones, Petoff y Murphy, O'Reilly, 2016) trata estos indicadores como la base para operar un servicio.
5. Dependencias y licencias
Las dependencias salen en lista: librerías, servicios, APIs, licencias que restringen uso comercial y proveedor único detrás de un componente crítico.
6. Personas y conocimiento
La prueba final es un conteo. Suma quién conoce cada sistema crítico. Si el sistema completo cabe en dos personas, el riesgo de continuidad entra en la evaluación.
Los hallazgos que más aparecen
Concentración de conocimiento. Dos ingenieros saben cómo funciona todo el sistema y nada está escrito. Cuando uno se va, el comprador anota un riesgo de continuidad y lo descuenta del valuation.
Seguridad postergada. Una contraseña versionada en un repositorio, una dependencia con un CVE de dos años, autenticación armada en un fin de semana. Cada corrección tiene precio y el comprador los suma en el presupuesto de integración.
Arquitectura contra el plan. El pitch proyecta 10x de crecimiento en 18 meses y el sistema llega solo después de refactorizar. La estimación de esa refactorización entra en el costo de la transacción.
Quién la conduce y cuándo
Agenda la due diligence técnica antes del term sheet. Un problema encontrado antes del term sheet entra en la negociación. El mismo problema encontrado después se vuelve una concesión de última hora.
El revisor correcto es un Staff Engineer o arquitecto sénior con paso por varios contextos. Will Larson detalla el alcance de ese perfil en Staff Engineer (O'Reilly, 2021). El equipo interno del adquirente califica su propia operación, y un generalista sin profundidad técnica se queda sin los problemas que importan.
El proceso dura de 5 a 10 días hábiles y devuelve un informe con resumen ejecutivo, análisis por dimensión y correcciones priorizadas con estimación de esfuerzo.
El lado del vendedor
Si estás del lado de la venta, abres el material antes de que llegue el revisor. Un revisor experimentado ayuda a explicar lo que existe, a dar contexto a los trade-offs que se ven mal en superficie y a organizar la documentación que acelera el cronograma.
Una empresa que llega con código, métricas y decisiones documentadas genera confianza el primer día de sala de datos.
