Due diligence técnica: checklist antes de levantar

La due diligence técnica no es un examen que apruebas por tener código limpio. Es un inversor averiguando una sola cosa: si la ingeniería puede absorber el dinero sin romperse, y si hay algo dentro capaz de destruir el valor de la empresa después de transferir.

Saber qué miran te permite arreglar los hallazgos caros mientras todavía son baratos.

Qué se revisa de verdad

Área	La pregunta de fondo
Propiedad del código	¿La empresa es dueña de lo que vende?
Licencias	¿Hay una dependencia que te obligue a liberar tu producto?
Seguridad y datos	¿Hay una brecha esperando, o un regulador con un reclamo?
Riesgo de persona clave	¿Qué pasa si se va una persona concreta?
Capacidad de entregar	¿El equipo puede absorber cinco ingenieros más e ir más rápido, no más lento?
Costo de operación	¿La economía unitaria sobrevive a diez veces el uso?

Fíjate en que la calidad del código no es una fila. Importa solo donde afecta a alguna de estas.

Propiedad, que es donde mueren los tratos

Esta es la que mata rondas, y es completamente evitable.

Toda persona que haya escrito código para ti, empleados, contratistas, un cofundador que se fue, una agencia, el amigo que hizo el primer prototipo, debe haber cedido la propiedad intelectual a la empresa por escrito. Un contratista sin cláusula de cesión es dueño por defecto de lo que escribió en muchas jurisdicciones. Descubrir eso durante la diligencia es, en el mejor caso, un retraso.

Revisa también que la empresa, y no una cuenta personal, sea dueña de los repositorios, las cuentas de nube, el dominio, las fichas de las tiendas de apps y la cuenta de Stripe. Los fundadores crean todo eso a título personal el día uno y nunca lo migran. Es un arreglo fácil en el mes uno e incómodo en un data room.

Licencias

Genera un reporte de licencias de dependencias y léelo. Buscas licencias copyleft, GPL y AGPL en particular, en cualquier cosa que distribuyas o ejecutes como servicio. AGPL en un producto alojado es la que de verdad asusta a los abogados.

Esto toma una tarde con herramientas estándar y es lo más barato de esta lista. También es lo que más probablemente produzca una sorpresa, porque las dependencias llegan de forma transitiva y nadie las eligió.

Seguridad, al nivel que los inversores realmente sondean

Nadie espera que una startup tenga una certificación formal en seed. Esperan que lo básico sea inequívoco:

• Ningún secreto en el repositorio, incluido su historial. Rota todo lo que alguna vez se commiteó, porque el historial es para siempre.
• Autenticación de múltiples factores en nube, control de versiones, correo y pasarela de pagos.
• Cifrado en reposo y en tránsito, que es sobre todo cuestión de no haber desactivado los valores por defecto.
• Control de acceso nominal, para que quien se va pierda el acceso y puedas mostrar quién tiene qué.
• Respaldos que se hayan restaurado al menos una vez. Un respaldo sin probar es una creencia, no un control.
• Una respuesta escrita sobre datos personales: qué guardas, dónde vive, cómo se borra a petición.

Riesgo de persona clave

La pregunta es directa: si tu ingeniero principal renuncia mañana, ¿qué se detiene?

Lo que tranquiliza a un inversor no es un héroe, es la ausencia de uno. Decisiones de arquitectura escritas. Más de una persona que haya desplegado a producción. Un runbook para las tareas operativas recurrentes. Credenciales en un gestor compartido y no en un portátil.

Si una sola persona es la única que entiende el despliegue, eso es un hallazgo, y normalmente se descubre preguntando a un ingeniero júnior, no leyendo documentos.

Capacidad de entregar

Los inversores compran velocidad futura. Las señales son poco lucidas y fáciles de producir si ya trabajas así:

• Pruebas automatizadas en las rutas que tocan dinero e identidad. No todo. Esas.
• Integración continua que de verdad bloquee un merge roto.
• Entornos separados de desarrollo, staging y producción.
• Despliegues rutinarios y reversibles, no acontecimientos.
• Monitoreo de errores y alertas que alguien recibe.

Son las mismas prácticas que cubrimos en nuestra guía para elegir agencia, por la misma razón: son lo que distingue a un equipo que puede seguir avanzando de uno que ya está frenando.

Costo de operación

Ten lista la respuesta a cuánto te cuesta un cliente en infraestructura, y qué pasa con ese número a diez veces el volumen. Si tu producto usa IA, cuenta con preguntas específicas sobre gasto de tokens por usuario, porque es la única partida que no se amortiza con la escala. Nuestra nota sobre bajar la factura de un LLM cubre las palancas que un inversor asumirá que conoces.

Un checklist que vale la pena recorrer

1. Cesión de propiedad intelectual firmada por todo colaborador pasado y presente.
2. La empresa, no una persona, es dueña de repos, nube, dominio, tiendas y cuentas de pago.
3. Reporte de licencias de dependencias sin sorpresas copyleft.
4. Ningún secreto en el historial de git, y rotado todo lo que alguna vez se commiteó.
5. Autenticación de múltiples factores en todo lo que importa.
6. Una restauración desde respaldo realizada y fechada.
7. Decisiones de arquitectura escritas, aunque sea brevemente.
8. Dos personas capaces de desplegar.
9. Pruebas y CI en las rutas de dinero e identidad.
10. Costo de infraestructura por cliente, con una proyección.

Los puntos uno a cinco son donde se retrasan los tratos. También son los cinco que puedes terminar en una semana.

Preguntas frecuentes

Por dónde empezar

Lista a toda persona que haya escrito código para la empresa y confirma que cada una firmó una cesión de propiedad intelectual. Ese solo ejercicio toma una mañana y resuelve la causa más común de que una ronda se retrase.

Si vas camino de levantar y quieres que miren la ingeniería antes que un inversor, hablemos. Sale bastante más barato encontrarlos tú.