Due Diligence Técnico en 2026: lo que VCs y compradores realmente deberían mirar

La mayoría de reportes de due diligence técnico que reciben los VCs son 40 páginas de nada. Un resumen del pitch deck del target, screenshots de su consola de AWS, y un párrafo sobre “arquitectura de microservicios escalable” escrito por alguien que nunca abrió el codebase. El associate que lo encargó lo hojea, el partner firma el term sheet, y 18 meses después la portfolio company está reescribiendo todo porque la plataforma original está pegada con cron jobs y el único ingeniero que entiende el flujo de pagos acaba de renunciar.

El DD técnico real es trabajo de ingeniería. No de consultoría. Requiere personas que hayan enviado sistemas a producción metidas en el codebase durante una semana haciendo preguntas incómodas. Así lo corremos nosotros.

Por qué la mayoría de DD de VC es superficial

Las prácticas de DD del Big Four entregan reportes a $80-150K. La mayor parte de ese precio compra proceso. Tres associates con background de consultoría general entrevistan al CTO, corren un scan de Snyk, cuentan líneas de código, generan gráficos. El entregable se ve profesional. Ninguno de los hallazgos sorprende al fundador.

Lo que realmente necesitas: un ingeniero con 10+ años de experiencia que lee el código, habla con el equipo sin el CTO en la sala, corre el pipeline de deploy él mismo, y te dice en español plano dónde están los cadáveres. Ese trabajo nos cuesta $7-25K dependiendo del tamaño de la empresa y lo entregamos en 1-3 semanas.

Los inversionistas que se queman no son los que saltaron el DD. Son los que pagaron $100K por un DD que confirmó lo que querían oír.

El framework de 5 áreas que usamos

Evaluamos cada target en cinco dimensiones. Cada una recibe un score de 1-5, una lista de evidencia, y una estimación de remediación en engineering-months.

1. Calidad de código

Bajamos el repo y lo leemos. Sí, realmente lo leemos. Miramos:

• Cobertura de tests que signifique algo. No el número de line-coverage del CI — el test suite real. ¿Hay integration tests alrededor del flujo de dinero? ¿Alrededor del auth? ¿Alrededor del contrato de la API que ven los clientes? Un repo con 70% de line-coverage sin integration tests es peor que uno con 30% y contract tests sólidos.
• Cadencia y profundidad de PRs. Bajamos los últimos 90 días de PRs. ¿Los reviews son sustantivos o sellos de goma? ¿Los PRs están squashed en commits “WIP” o cuentan una historia? ¿Una sola persona revisa el 80% de los merges (key-person risk)?
• Arqueología de código. git blame sobre los 20 archivos de mayor tráfico. Si el 60% del código de critical-path fue escrito por una persona que se fue hace 8 meses, ese es un hallazgo que el fundador no va a ofrecer voluntariamente.
• Densidad de TODO y FIXME. Un repo con 400 FIXMEs sin resolver tiene una cultura operativa distinta a uno con 12.

2. Arquitectura y escalabilidad

El pitch deck dice “podemos escalar a 10M de usuarios”. Probamos la afirmación. No confiando en los slides de AWS — leyendo los hot paths reales.

• ¿El sistema de auth es un modelo monolítico de shared-secret o soporta multi-tenancy limpiamente?
• ¿Dónde se esconden los N+1 queries? Corremos EXPLAIN ANALYZE sobre los top 20 query patterns.
• ¿Cuál es la tasa real de crecimiento de la base de datos vs el diseño del schema? Un B2B SaaS guardando todos los eventos de clientes en una sola tabla de Postgres sin particionar es una bomba de tiempo de 9 meses.
• ¿Cómo falla el sistema bajo carga? Miramos los últimos 6 meses de incidentes y post-mortems (si existen). No tener post-mortems es en sí mismo un hallazgo.

3. Postura de seguridad

La mayoría de targets en etapa temprana no tienen programa de seguridad. Se espera. Lo que evaluamos es si los gaps son los gaps normales de startup o los gaps que van a torpedear ventas enterprise.

Corremos:

• Un scan SAST (Semgrep, GitHub Advanced Security) buscando clases de vulnerabilidad conocidas.
• Una pasada DAST contra staging (OWASP ZAP, Burp Suite) sobre la superficie pública.
• Un threat model de la capa de auth y autorización — no por compliance, por paths de atacante reales.
• Una revisión de manejo de secretos. Si encontramos AWS keys en el repo, eso no es un hallazgo, es una llamada al partner el mismo día.
• Revisión de IAM y config de cloud. Buckets S3 públicos, roles permisivos, uso de root account, sin MFA en la org de GitHub. Las cosas aburridas que causan breaches.

También preguntamos: ¿esta empresa puede pasar un SOC 2 Type I en 90 días, o le va a tomar 9 meses? Eso responde si el revenue enterprise está bloqueado por 1 trimestre o 1 año.

4. Madurez de DevOps y operación

• ¿Un ingeniero nuevo puede hacer deploy en su primer día? Intentamos seguir el README. Si la respuesta es “el deploy script solo funciona en la laptop de Andrés”, lo marcamos.
• ¿La infraestructura está en Terraform / Pulumi / CDK, o es ClickOps? Una empresa de 4 años sin IaC es una remediación de 6 meses.
• ¿Cómo se ve la rotación de on-call? Si no hay rotación y el CTO carga el pager solo, la empresa tiene un riesgo de personnel oculto.
• Backups y disaster recovery. La mayoría de targets nunca probó un restore. Les pedimos que lo hagan.

5. Equipo y cultura

Esta es la dimensión que la mayoría de reportes de DD saltan, y la que decide si el plan de integración o de post-inversión sobrevive al contacto con la realidad.

Entrevistamos ingenieros sin el CTO presente. Preguntas que hacemos:

• “Cuéntame cómo un feature pasa de idea a producción.”
• “¿Cuál es la peor pieza de deuda técnica en el codebase, y por qué no se ha arreglado?”
• “Cuéntame la última vez que estuviste en desacuerdo con una decisión técnica. ¿Cómo terminó?”
• “¿A quién no quisieras perder?”

Las respuestas del CTO y las del equipo deben rimar. Cuando no riman, encontraste algo. La versión más común de “no riman”: el CTO cree que el equipo está empoderado; los ingenieros describen una cultura donde push back te apaga la voz.

Red flags que deberían matar o reprecisar el deal

Algunos hallazgos son interesantes. Otros son dealbreakers. Los que nos hacen agarrar el teléfono al partner a mitad del engagement:

• Cero tests. No baja cobertura — cero tests significativos en un codebase de 4 años. No es flojera; es una cultura que envía y reza.
• Un solo monolito desplegable sin module boundaries y un equipo de 12 ingenieros todos tocándolo. La velocidad ya colapsó; los fundadores aún no lo admiten.
• Auth añadido después de los hechos. Permisos chequeados en el UI pero no en la API. Usualmente podemos demostrar un IDOR (insecure direct object reference) en una tarde.
• Sin CI o un CI que ha estado en rojo por semanas. Te dice todo sobre la cadencia operativa.
• Dependencia de una sola persona en un sistema crítico. “Solo Ravi entiende el billing service.” Ravi ahora es un riesgo de $5M en tu cap table.
• Datos de clientes sin encryption at rest, en un backup sin encryption, en un bucket S3 público. Lo hemos visto. Más de una vez.

Menos catastrófico pero digno de reprecio: dependencia fuerte de un servicio propietario de un solo cloud vendor sin abstracción (lock-in), APIs críticas de terceros sin fallback (dependencias de DocuSign, Stripe Connect, Twilio que no están aisladas), branches de código específicas por cliente en main (la empresa secretamente es una consultora).

Cómo se ve un buen entregable de DD

Nuestro entregable tiene tres capas, escritas para tres audiencias.

Capa 1: Executive summary (2-3 páginas). Para el investment committee. Español plano. Top 5 riesgos, top 5 fortalezas, recomendación (proceder / proceder con condiciones / pasar), y un párrafo con el presupuesto de remediación.

Capa 2: Hallazgos técnicos (15-25 páginas). Para el CTO que va a trabajar con este equipo post-cierre. Cada hallazgo tiene: qué observamos, evidencia (commits, paths de archivos, screenshots), severidad, y una estimación de remediación en engineering-weeks.

Capa 3: Artefactos crudos. Outputs de scans, diagramas de threat model, query plans, screenshots de hallazgos de consola. Auditable. El equipo técnico del comprador puede reproducir nuestro trabajo.

El presupuesto de remediación es la parte más útil para reprecio. “La plataforma necesita $400K y 4 meses de trabajo de ingeniería para llegar a confiabilidad grado-comprador” es un número que puedes restar de la valuación. “Su codebase tiene algo de deuda técnica” no lo es.

Herramientas que sí usamos

No somos religiosos con tooling pero acá está el kit estándar:

• Análisis de código: Semgrep, GitHub Advanced Security, SonarQube para algunos engagements, revisión manual para todo lo que importa.
• Dependencias / SCA: Snyk, Dependabot, OSV-Scanner.
• DAST: Burp Suite Pro, OWASP ZAP para la pasada open-source.
• Config de cloud: AWS Security Hub, ScoutSuite, Prowler. Para GCP, Forseti o Cloud Security Command Center.
• Revisión de infra: Diffs de terraform plan, drift detection vía terraform plan contra el estado real.
• Métricas de codebase: Scripts custom que sacan distribución de contributors, churn a nivel de archivo, densidad de comentarios. Nada mágico; solo lo suficiente para marcar concentration risk.

Las herramientas no son el diferenciador. El juicio sobre cuáles hallazgos importan, sí.

Precio y timing

• Tech DD estándar para un target Series A (15-30 ingenieros, 1-3 productos): desde $7K, 1-3 semanas.
• DD de adquisición para un target más grande o donde se necesita planning de integración post-cierre: $15-25K, 2-4 semanas.
• Pre-investment lite review cuando quieres una segunda opinión en 5 días: $3-5K, 5 días hábiles.

Firmamos NDA mutuo antes del kickoff. Trabajamos bajo el nombre del comprador o inversionista (el target no ve “Softronic” en ningún lado si prefieres). Todos los hallazgos son tuyos.

Conclusión

Si estás escribiendo un cheque arriba de $2M, pagar 0.3-0.5% del tamaño del cheque por DD de ingeniería independiente es el seguro más barato que puedes comprar. La mayor parte del tiempo vas a confirmar lo que ya creías y proceder con más convicción. A veces vas a atrapar la cosa que te hubiera costado el fondo.

Podemos arrancar un engagement de tech DD la próxima semana. La primera llamada de 30 minutos es gratis e incluye una conversación de scoping.