La due diligence técnica no es una revisión de código. Es la respuesta a una pregunta: ¿cuánto costará llevar esta tecnología hasta donde la tesis de inversión la necesita?
La mayoría de las due diligences técnicas produce un documento que nadie usa. Enumera frameworks, cuenta tests, señala que la documentación podría ser mejor — y luego el acuerdo se cierra o no por razones totalmente ajenas. Eso desperdicia una oportunidad real de poner precio al riesgo.
Una due diligence técnica útil responde a tres preguntas en términos de negocio: ¿puede esta tecnología sostener el plan que estás financiando, cuánto costará cerrar las brechas y qué riesgos pueden destruir valor en lugar de solo ralentizarlo?
Para qué sirve realmente la due diligence técnica
Un inversor de capital riesgo no compra una base de código. Compra una tesis: este equipo alcanzará esa escala en este plazo. La tecnología importa solo donde hace esa tesis más o menos probable.
| La tesis dice | Por tanto la diligencia debe establecer |
|---|---|
| Crecimiento ×10 de usuarios en 24 meses | Dónde se rompe la arquitectura y cuánto cuesta subir ese techo |
| Expansión a la UE | Si el tratamiento de datos sobrevive al RGPD y cuánto cuesta una versión conforme |
| Esto es un negocio de pagos | Integridad del libro mayor, idempotencia, conciliación — lo que pierde dinero real |
| El equipo sabe ejecutar | Rendimiento de entrega y bus factor, no la calidad de los CV |
| Tecnología defendible | Si el foso es ingeniería real o una capa fina sobre la API de otro |
Las cinco áreas que importan
1. Arquitectura y margen de escalado
Todo sistema tiene un techo. La pregunta es dónde está respecto al plan y cuán caro es elevarlo. Un monolito que sirve 100.000 usuarios sin problema no es un hallazgo; un monolito con una única base de datos maestra de escritura y un plan de crecimiento a 10 millones sí lo es.
- Los puntos únicos de fallo — y si el equipo sabe cuáles son
- La capa de datos — normalmente el techo real y lo más caro de cambiar después
- Si la carga se ha probado alguna vez, o el escalado se da por supuesto
- Curva de coste cloud: ¿sobrevive la unit economics a ×10, o la infraestructura se come el margen?
2. Integridad del dinero y los datos
Para cualquier empresa que toque pagos, saldos o datos regulados, esta es el área donde equivocarse cuesta más — y la que más se salta, porque inspeccionarla exige conocimiento de dominio.
- ¿El saldo se deriva de un libro mayor inmutable, o es un número mutable que el código puede sobrescribir?
- Idempotencia en las rutas de pago y webhook — ¿puede un reintento cobrar dos veces?
- Dinero guardado como enteros en unidades menores, nunca como float
- Conciliación: ¿se detectaría internamente una discrepancia, o la detectaría un cliente?
3. Exposición de seguridad y cumplimiento
Los hallazgos de seguridad solo tienen sentido ligados a una consecuencia. «Las dependencias están desactualizadas» es ruido. «Un endpoint sin autenticar devuelve registros de otros clientes» es una cláusula del acuerdo.
- Autorización aplicada en el servidor en cada petición, no escondida en la interfaz
- Aislamiento multi-tenant — con diferencia el hallazgo serio más común en SaaS B2B
- Gestión de secretos y si hay credenciales en el historial de git
- Qué datos regulados se almacenan — y si deberían almacenarse siquiera
- Distancia a la certificación que exige el go-to-market (SOC 2, ISO 27001, PCI DSS)
4. Capacidad de entrega
Esto predice los próximos dos años mejor que la base de código actual. Una base de código mediocre con disciplina de entrega fuerte mejora. Una base de código elegante sin capacidad de desplegar con seguridad, no.
- Frecuencia de despliegue y tiempo de entrega de un cambio pequeño
- Si el rollback es rutina practicada o teoría
- Cobertura de test en las rutas que importan (dinero, auth) en vez de un porcentaje global
- Detección de incidentes: ¿encuentran los problemas antes que los clientes?
5. Riesgo de equipo y persona clave
- Bus factor: cuántas personas entienden los subsistemas críticos — si la respuesta es una, eso es riesgo de operación
- Si el conocimiento existe fuera de las cabezas
- Dependencia de contratistas sobre la PI central, y si la cesión de PI está limpia
- Realismo del plan de contratación frente al roadmap que se financia
Señales de alarma, ordenadas por lo que cuestan de verdad
| Hallazgo | Gravedad | Por qué |
|---|---|---|
| Saldos mutables / sin libro mayor en una fintech | Nivel operación | Las pérdidas son ilimitadas y pueden haber ocurrido ya sin detectarse |
| Acceso a datos entre tenants | Nivel operación | Una filtración termina con las ventas enterprise y activa a los reguladores |
| Un solo ingeniero concentra todo el conocimiento crítico | Alta | Su salida reinicia el roadmap |
| Sin automatización de despliegue | Alta | Limita el rendimiento por muchos que contrates |
| Propiedad intelectual poco clara con contratistas | Alta | Legal, no técnico — pero mata las salidas |
| Dependencias desactualizadas | Baja | Mantenimiento rutinario, cuantificable en días |
| Estilo de código inconsistente | Ruido | Ignorar |
El propósito de la due diligence técnica no es encontrar un motivo para retirarse. Es saber con precisión qué estás comprando, para que el precio y el plan lo reflejen.
Cómo se traducen los hallazgos en términos del acuerdo
- Presupuesto de remediación — cuantificar las correcciones y financiarlas explícitamente en la ronda en vez de descubrirlas en el mes seis
- Condiciones por hitos — liberación de tramos ligada a remediaciones concretas (habitual cuando brechas de cumplimiento bloquean el go-to-market)
- Ajuste de valoración — donde la remediación es grande respecto a la ronda
- Plan post-cierre — un roadmap técnico a 90 días acordado antes de la transferencia, no improvisado después
Cuánto tarda
| Profundidad | Duración | Cuándo usarla |
|---|---|---|
| Cribado | 2-3 días | Etapa temprana, cheque pequeño, solo comprobación de cordura |
| Estándar | 1-2 semanas | La mayoría de rondas Series A / Series B |
| Profunda | 3-4 semanas | Fintech, healthtech, cheque grande, u objetivo conocido por su desorden |
Más largo no es mejor. Pasadas dos semanas, la mayoría de encargos produce detalle en vez de decisiones — salvo que el dominio lo exija de verdad, como en pagos o datos sanitarios regulados.
Delimitar la revisión antes de recopilar documentos
La revisión debe responder a la tesis de inversión. Define preguntas, sistemas materiales y evidencias antes de puntuar riesgos.
- Relacionar crecimiento previsto con capacidad y costes observados.
- Separar declaraciones, pruebas verificadas e información no disponible.
- Distinguir condiciones previas al cierre y plan financiado posterior.
Preguntas frecuentes
¿Qué diferencia hay entre due diligence técnica y auditoría de código?
Una auditoría de código examina la calidad del código. La due diligence técnica examina si la tecnología, el equipo y el proceso de entrega pueden sostener un plan de negocio concreto — y cuánto cuestan las brechas. El código es una de cinco entradas; arquitectura, seguridad, capacidad de entrega y riesgo de persona clave suelen pesar más en la decisión de inversión.
¿Quién paga la due diligence técnica?
Casi siempre el inversor, como parte de los costes de la operación. Ocasionalmente un fundador la encarga antes de levantar para encontrar y arreglar problemas antes que los inversores — normalmente dinero bien gastado, porque los hallazgos que descubre la otra parte cuestan mucho más en negociación que en ingeniería.
¿Hace falta la cooperación de la startup?
Sí. Una diligencia con sentido necesita acceso de lectura al repositorio, un recorrido por la arquitectura y una conversación con los ingenieros. Un objetivo que se resiste a esto es en sí mismo un hallazgo digno de anotar.
¿Se puede hacer una due diligence técnica en unos días?
Una pasada de cribado sí, y detectará de forma fiable problemas de categoría: sin libro mayor en una empresa de pagos, sin automatización de despliegue, bus factor de uno. No te dirá cuánto cuesta la remediación. Para una ronda con valoración, una o dos semanas son el mínimo realista.
¿Puede continuar la revisión con acceso limitado?
Sí, con alcance reducido y límites explícitos. Documenta incertidumbres y solicita las evidencias que faltan antes de confiar en la conclusión.
¿Diligencia sobre una participada?
Entregamos hallazgos ordenados por impacto de negocio, con costes de remediación que puedes llevar a la negociación — en una o dos semanas.
Para seguir leyendo
Auditoría de código previa a la inversión: qué pedir antes de transferir
Estás a punto de comprar una participación en un activo que no has inspeccionado. La auditoría de código es la inspección — pero solo si se acota para responder preguntas de inversión y no de ingeniería.
Auditoría técnica de MVP: qué revisamos en las primeras 48 horas
La mayoría de las auditorías de MVP producen un documento. Una útil produce decisiones: qué está ardiendo, qué puede esperar y cuánto cuesta arreglarlo.