Due diligence técnico para inversores: qué revisar antes de invertir
Por qué los inversores necesitan una radiografia técnica
El 42% de las adquisiciones tecnológicas que no alcanzan sus objetivos de sinergias fallan por problemas técnicos no detectados durante la due diligence. La cifra es de Bain & Company, 2024, y no sorprende a nadie que haya visto por dentro una startup de serie A con un producto funcional y un código que no sobreviviría seis meses de crecimiento.
El due diligence financiero y legal son prácticas maduras. El due diligence técnico sigue siendo, en muchas operaciones, una revisión superficial: un vistazo al stack tecnológico, una pregunta sobre el uptime, y poco más. El resultado es que inversores acaban descubriendo problemas de escalabilidad, deuda técnica o dependencia de personal clave cuando ya han firmado.
Esta guía detalla lo que revisamos cuando un fondo o un family office nos pide evaluar la tecnología de una empresa objetivo.
Las cinco áreas de revisión
Organizamos la due diligence técnica en cinco áreas, cada una con indicadores cuantificables y banderas rojas.
1. Calidad de código y prácticas de desarrollo
No se trata de si el código es “bonito.” Se trata de si es mantenible, testeable y seguro.
Indicadores que medimos: cobertura de tests (por debajo del 30% es bandera roja), frecuencia de despliegues (menos de uno al mes sugiere procesos frágiles), tiempo medio de resolución de bugs críticos (más de 5 días es preocupante), y presencia de linters, formatters y CI/CD en el pipeline.
Herramientas que usamos: SonarQube para análisis estático, Semgrep para vulnerabilidades de seguridad, y revisión manual de una muestra representativa del repositorio. La revisión manual es insustituible. Un análisis automático te dice que hay 200 code smells. Un ingeniero senior te dice cuáles de esos 200 importan y cuáles son ruido.
Bandera roja crítica: ausencia total de tests automatizados. Una base de código sin tests no es solo un problema de calidad; es un indicador de que el equipo no puede hacer cambios con confianza, lo que ralentiza la evolución del producto.
2. Arquitectura y escalabilidad
La pregunta central no es “cuál es la arquitectura actual” sino “puede la arquitectura actual soportar 10x el volumen actual sin una reescritura?”
Revisamos: separación de responsabilidades (un monolito bien estructurado es aceptable; un monolito con todo acoplado no lo es), gestión de estado (dónde vive el estado, cómo se sincroniza), estrategia de base de datos (índices, particionamiento, plan de crecimiento), y dependencias externas (APIs de terceros sin fallback son puntos de fallo únicos).
Lo que buscamos específicamente: cuellos de botella predecibles. Una tabla SQL de 50 millones de filas sin particionamiento. Un servicio síncrono que llama a una API externa con timeout de 30 segundos en el hilo principal. Un sistema de colas que es en realidad un cron job que hace polling cada minuto. Estos no son problemas abstractos; son problemas que explotarán a una escala predecible.
En una due diligence reciente para una fintech española, encontramos que toda la lógica de reconciliación de pagos vivía en un stored procedure de 2.400 líneas en PostgreSQL. Funcionaba. Pero si el volumen de transacciones se duplicaba (lo que el plan de negocio previa en 18 meses), la base de datos no aguantaría. Cuantificamos el coste de extraer esa lógica: 3 meses de un equipo de 2 ingenieros. Esa cifra afectó directamente a la valoración.
3. Cuantificación de deuda técnica
La deuda técnica no es inherentemente mala. Es mala cuando no está cuantificada, no está priorizada, y no hay plan para pagarla.
Categorizamos la deuda en tres niveles:
- Deuda crítica: Problemas que bloquearán el crecimiento o causarán incidentes. Requieren intervención en los próximos 3-6 meses. Ejemplos: base de datos sin backups automatizados, secretos hardcodeados en el repositorio, dependencias con vulnerabilidades conocidas.
- Deuda significativa: Problemas que reducen la velocidad del equipo o incrementan el riesgo. Plan de resolución en 6-12 meses. Ejemplos: módulos de código sin tests que se modifican frecuentemente, integraciones frágiles, documentación de API inexistente.
- Deuda aceptable: Decisiones conscientes de tomar atajos que no afectan la operación ni el crecimiento a corto plazo. Ejemplos: uso de librerías legacy pero estables, código duplicado en áreas de bajo cambio.
Para cada elemento de deuda crítica y significativa, estimamos el coste de remediación en semanas-persona. Esto convierte un concepto abstracto (“hay mucha deuda técnica”) en un número que un inversor puede incorporar a su modelo financiero.
4. Seguridad y cumplimiento
La seguridad no es un área separada; es una dimensión transversal. Pero por su impacto en el riesgo de inversión, merece revisión dedicada.
Checklist mínimo: gestión de secretos (Vault, AWS Secrets Manager, o al menos variables de entorno, nunca en código), HTTPS en todos los endpoints, autenticación y autorización implementadas (no solo un login: control de acceso por roles, tokens con expiración), cifrado en reposo para datos sensibles, y compliance con RGPD si opera en Europa (delegado de protección de datos, registro de actividades, política de retención).
Para empresas fintech la revisión se extiende a PCI DSS (si manejan datos de tarjetas), PSD2 (si ofrecen servicios de pago), y regulación MiCA si operan con cripto. Los gaps de compliance no son solo riesgo operativo; son riesgo legal que puede invalidar la inversión.
Herramientas: Semgrep y Snyk para vulnerabilidades en código y dependencias, un pentest básico (Burp Suite o equivalente) contra los endpoints públicos, y revisión de la configuración de infraestructura cloud (SecurityHub en AWS, Security Command Center en GCP).
5. Equipo y capacidad de ejecución
La tecnología la construyen personas. Revisamos: tamaño y estructura del equipo (un CTO que también es el único desarrollador es un riesgo de persona clave), rotación en los últimos 12 meses (rotación superior al 30% anual es bandera roja), distribución de contribuciones en el repositorio (si el 80% de los commits son de una persona, hay concentración de conocimiento), y capacidad de contratación (si necesitan duplicar el equipo en 12 meses, es factible con la marca y la ubicación que tienen?).
Un patrón que vemos frecuentemente: startups con un equipo técnico de 3-4 personas que ha construido un producto funcional a velocidad impresionante, pero con prácticas de desarrollo que solo funcionan a esa escala. Sin documentación, sin procesos, sin separación de entornos. Lo que los hizo rápidos siendo 3 los hará lentos siendo 15. El plan de inversión debe incluir un periodo de profesionalización del equipo, y eso tiene un coste que el inversor debe conocer.
El entregable: qué recibe el inversor
Nuestro informe de due diligence técnica tiene una estructura fija:
- Resumen ejecutivo (1 página): veredicto general, riesgos críticos, coste estimado de remediación.
- Evaluación por área (5 secciones): cada área con puntuación 1-5, hallazgos, evidencias y recomendaciones.
- Matriz de riesgos: probabilidad vs impacto para cada hallazgo crítico y significativo.
- Estimación de costes de remediación: en semanas-persona y en euros, con rangos.
- Preguntas abiertas: cuestiones que requieren información adicional que no estuvo disponible durante la revisión.
El timeline típico es de 2-3 semanas, dependiendo del tamaño del codebase y la colaboración del equipo objetivo. El coste se mueve entre 8.000 y 25.000 euros dependiendo del alcance.
Cuando la tecnología cambia la valoración
En nuestra experiencia, un 30% de las due diligences revelan problemas que ajustan la valoración a la baja. No necesariamente matan la operación: a veces el producto y el mercado justifican la inversión incluso con deuda técnica significativa. Pero el inversor entra con los ojos abiertos y con un plan de remediación presupuestado.
El otro 70% confirma que la tecnología es sólida o tiene problemas menores. Esa confirmación también tiene valor: elimina incertidumbre y da confianza al comité de inversión.
Si estás evaluando una inversión en una empresa con componente tecnológico, nuestro equipo de consultoría tecnológica realiza due diligences técnicas con entregables accionables. No es un nice-to-have. Es la diferencia entre invertir con datos y invertir con esperanza.
