La negociación marchaba bien. Valuations alineados, términos avanzados, equipos entusiasmados. Entonces llegó la due diligence técnica, y el revisor encontró: sistema monolítico sin tests, tres ingenieros con conocimiento crítico de sistemas de los que la empresa dependía, deuda de seguridad en múltiples capas y una arquitectura que hacía inviable la integración con el stack del adquirente.
Ese escenario no es una excepción. Ocurre con más frecuencia de lo que la mayoría de las personas del lado financiero imagina. Y el costo (en ajuste de valuation, en obligaciones post-cierre o en una negociación perdida) es alto.
Qué es la due diligence técnica
La due diligence técnica es el proceso de evaluar el estado real de los activos tecnológicos de una empresa antes de una transacción: sea una adquisición, una ronda de serie A en adelante, o una fusión.
No es una auditoría de código línea por línea. Es un análisis estructurado de la salud del sistema, de las prácticas de ingeniería, de los riesgos operativos y de la capacidad de escalar y evolucionar la tecnología.
El objetivo no es encontrar motivos para tumbar la negociación. Es darle al adquirente o inversor una visión honesta de lo que está comprando, y al vendedor, la oportunidad de explicar contexto que los números por sí solos no muestran.
Las seis dimensiones que deben evaluarse
1. Arquitectura y escalabilidad
¿El sistema aguanta crecimiento? ¿La arquitectura actual es un activo o un pasivo para los próximos 3 años? ¿Existen cuellos de botella conocidos que solo aparecen a escala? ¿La deuda de arquitectura está gestionada o está fuera de control?
2. Calidad de código y cobertura de tests
¿Cuál es la cobertura de tests automatizados? ¿El código sigue estándares consistentes? ¿Existen áreas del sistema que nadie puede modificar sin miedo a romper algo? ¿Cuál es la tasa de bugs en producción por mes?
3. Seguridad
¿Existe alguna vulnerabilidad crítica en el sistema? ¿Cómo se gestionan secretos y credenciales? ¿Hay dependencias con vulnerabilidades conocidas sin corregir? ¿El sistema pasó por tests de penetración en los últimos 12 meses?
4. Infraestructura y operaciones
¿Cómo está estructurado el entorno de producción? ¿Cuál es el tiempo medio de recuperación en caso de incidente? ¿El deploy es automatizado y trazable? ¿Existen monitoreo y alertas adecuados?
5. Dependencias y licencias
¿Cuáles son las dependencias de terceros: librerías, servicios, APIs? ¿Existen licencias de software que restrinjan el uso comercial o la redistribución? ¿Hay riesgo de proveedor único en componentes críticos?
6. Personas y conocimiento
¿El conocimiento del sistema está distribuido o concentrado en una o dos personas? ¿Cómo es la documentación técnica? ¿El equipo de ingeniería tiene capacidad de sostener y evolucionar el producto sin los fundadores?
Lo que suele sorprender
Tras varios procesos de due diligence técnica, algunos patrones aparecen con frecuencia:
Concentración de conocimiento es el riesgo más subestimado. Dos ingenieros que saben cómo funciona todo el sistema, sin documentación adecuada, son un riesgo de continuidad de negocio que impacta directamente el valuation.
La seguridad no era prioridad en startups early-stage. Contraseñas en repositorios, dependencias desactualizadas con CVEs conocidos, autenticación improvisada: estos problemas aparecen con frecuencia y tienen un costo real de corrección.
La arquitectura no escala como sugiere el pitch deck. Cuando la empresa proyecta un crecimiento de 10x en 18 meses, la arquitectura necesita soportarlo. Muchas no lo soportan, y la estimación de refactorización para llegar ahí es parte del costo real de la transacción.
Cuándo hacerla y quién debe conducirla
La due diligence técnica debe ocurrir antes del term sheet en transacciones relevantes, no después. Los problemas encontrados antes del term sheet son más fáciles de negociar que las sorpresas post-cierre.
El revisor ideal es un Staff Engineer o arquitecto sénior con experiencia en múltiples contextos, no alguien del equipo interno del adquirente que tenga sesgos, ni un generalista que no puede evaluar profundidad técnica.
El proceso típico demora de 5 a 10 días hábiles y resulta en un informe estructurado con: resumen ejecutivo de los riesgos, análisis detallado por dimensión y recomendaciones con prioridad y estimación de esfuerzo para corrección.
Para quien está siendo adquirido
Si estás del lado del vendedor, la due diligence técnica no es una amenaza: es una oportunidad. Un revisor experimentado puede ayudar a articular lo que fue construido, contextualizar decisiones de trade-off que parecían malas en superficie y preparar la documentación que acelera el proceso.
Las empresas que llegan bien preparadas a la due diligence técnica transmiten confianza. Y la confianza, en procesos de M&A, tiene valor real.
