Due diligence tecnico para inversores: que revisar antes de invertir

Por que los inversores necesitan una radiografia tecnica

El 42% de las adquisiciones tecnologicas que no alcanzan sus objetivos de sinergias fallan por problemas tecnicos 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 codigo que no sobreviviria seis meses de crecimiento.

El due diligence financiero y legal son practicas maduras. El due diligence tecnico sigue siendo, en muchas operaciones, una revision superficial: un vistazo al stack tecnologico, una pregunta sobre el uptime, y poco mas. El resultado es que inversores acaban descubriendo problemas de escalabilidad, deuda tecnica o dependencia de personal clave cuando ya han firmado.

Esta guia detalla lo que revisamos cuando un fondo o un family office nos pide evaluar la tecnologia de una empresa objetivo.

Las cinco areas de revision

Organizamos la due diligence tecnica en cinco areas, cada una con indicadores cuantificables y banderas rojas.

1. Calidad de codigo y practicas de desarrollo

No se trata de si el codigo 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 fragiles), tiempo medio de resolucion de bugs criticos (mas de 5 dias es preocupante), y presencia de linters, formatters y CI/CD en el pipeline.

Herramientas que usamos: SonarQube para analisis estatico, Semgrep para vulnerabilidades de seguridad, y revision manual de una muestra representativa del repositorio. La revision manual es insustituible. Un analisis automatico te dice que hay 200 code smells. Un ingeniero senior te dice cuales de esos 200 importan y cuales son ruido.

Bandera roja critica: ausencia total de tests automatizados. Una base de codigo 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 evolucion del producto.

2. Arquitectura y escalabilidad

La pregunta central no es “cual es la arquitectura actual” sino “puede la arquitectura actual soportar 10x el volumen actual sin una reescritura?”

Revisamos: separacion de responsabilidades (un monolito bien estructurado es aceptable; un monolito con todo acoplado no lo es), gestion de estado (donde vive el estado, como se sincroniza), estrategia de base de datos (indices, particionamiento, plan de crecimiento), y dependencias externas (APIs de terceros sin fallback son puntos de fallo unicos).

Lo que buscamos especificamente: cuellos de botella predecibles. Una tabla SQL de 50 millones de filas sin particionamiento. Un servicio sincrono 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 explotaran a una escala predecible.

En una due diligence reciente para una fintech espanola, encontramos que toda la logica de reconciliacion de pagos vivia en un stored procedure de 2.400 lineas 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 aguantaria. Cuantificamos el coste de extraer esa logica: 3 meses de un equipo de 2 ingenieros. Esa cifra afecto directamente a la valoracion.

3. Cuantificacion de deuda tecnica

La deuda tecnica no es inherentemente mala. Es mala cuando no esta cuantificada, no esta priorizada, y no hay plan para pagarla.

Categorizamos la deuda en tres niveles:

• Deuda critica: Problemas que bloquearan el crecimiento o causaran incidentes. Requieren intervencion en los proximos 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 resolucion en 6-12 meses. Ejemplos: modulos de codigo sin tests que se modifican frecuentemente, integraciones fragiles, documentacion de API inexistente.
• Deuda aceptable: Decisiones conscientes de tomar atajos que no afectan la operacion ni el crecimiento a corto plazo. Ejemplos: uso de librerias legacy pero estables, codigo duplicado en areas de bajo cambio.

Para cada elemento de deuda critica y significativa, estimamos el coste de remediacion en semanas-persona. Esto convierte un concepto abstracto (“hay mucha deuda tecnica”) en un numero que un inversor puede incorporar a su modelo financiero.

4. Seguridad y cumplimiento

La seguridad no es un area separada; es una dimension transversal. Pero por su impacto en el riesgo de inversion, merece revision dedicada.

Checklist minimo: gestion de secretos (Vault, AWS Secrets Manager, o al menos variables de entorno, nunca en codigo), HTTPS en todos los endpoints, autenticacion y autorizacion implementadas (no solo un login: control de acceso por roles, tokens con expiracion), cifrado en reposo para datos sensibles, y compliance con RGPD si opera en Europa (delegado de proteccion de datos, registro de actividades, politica de retencion).

Para empresas fintech la revision se extiende a PCI DSS (si manejan datos de tarjetas), PSD2 (si ofrecen servicios de pago), y regulacion MiCA si operan con cripto. Los gaps de compliance no son solo riesgo operativo; son riesgo legal que puede invalidar la inversion.

Herramientas: Semgrep y Snyk para vulnerabilidades en codigo y dependencias, un pentest basico (Burp Suite o equivalente) contra los endpoints publicos, y revision de la configuracion de infraestructura cloud (SecurityHub en AWS, Security Command Center en GCP).

5. Equipo y capacidad de ejecucion

La tecnologia la construyen personas. Revisamos: tamano y estructura del equipo (un CTO que tambien es el unico desarrollador es un riesgo de persona clave), rotacion en los ultimos 12 meses (rotacion superior al 30% anual es bandera roja), distribucion de contribuciones en el repositorio (si el 80% de los commits son de una persona, hay concentracion de conocimiento), y capacidad de contratacion (si necesitan duplicar el equipo en 12 meses, es factible con la marca y la ubicacion que tienen?).

Un patron que vemos frecuentemente: startups con un equipo tecnico de 3-4 personas que ha construido un producto funcional a velocidad impresionante, pero con practicas de desarrollo que solo funcionan a esa escala. Sin documentacion, sin procesos, sin separacion de entornos. Lo que los hizo rapidos siendo 3 los hara lentos siendo 15. El plan de inversion debe incluir un periodo de profesionalizacion del equipo, y eso tiene un coste que el inversor debe conocer.

El entregable: que recibe el inversor

Nuestro informe de due diligence tecnica tiene una estructura fija:

1. Resumen ejecutivo (1 pagina): veredicto general, riesgos criticos, coste estimado de remediacion.
2. Evaluacion por area (5 secciones): cada area con puntuacion 1-5, hallazgos, evidencias y recomendaciones.
3. Matriz de riesgos: probabilidad vs impacto para cada hallazgo critico y significativo.
4. Estimacion de costes de remediacion: en semanas-persona y en euros, con rangos.
5. Preguntas abiertas: cuestiones que requieren informacion adicional que no estuvo disponible durante la revision.

El timeline tipico es de 2-3 semanas, dependiendo del tamano del codebase y la colaboracion del equipo objetivo. El coste se mueve entre 8.000 y 25.000 euros dependiendo del alcance.

Cuando la tecnologia cambia la valoracion

En nuestra experiencia, un 30% de las due diligences revelan problemas que ajustan la valoracion a la baja. No necesariamente matan la operacion: a veces el producto y el mercado justifican la inversion incluso con deuda tecnica significativa. Pero el inversor entra con los ojos abiertos y con un plan de remediacion presupuestado.

El otro 70% confirma que la tecnologia es solida o tiene problemas menores. Esa confirmacion tambien tiene valor: elimina incertidumbre y da confianza al comite de inversion.

Si estas evaluando una inversion en una empresa con componente tecnologico, nuestro equipo de consultoria tecnologica realiza due diligences tecnicas con entregables accionables. No es un nice-to-have. Es la diferencia entre invertir con datos y invertir con esperanza.