Due diligence técnica: cómo preparar tu startup para una ronda
Cuando una ronda avanza, llega el momento en que el fondo manda a alguien a mirar por dentro lo que has construido: el código, la arquitectura, la seguridad y a quién pertenece realmente. Esa revisión es la due diligence técnica, y lo que encuentre puede mover tu valoración, meter cláusulas en el term sheet o retrasar el cierre meses. La buena noticia: casi todo lo que van a encontrar puedes encontrarlo tú antes.
Lo esencial
- La due diligence técnica es la auditoría que el inversor hace de tu tecnología antes de firmar. Aparece con fuerza a partir de Serie A, aunque en rondas semilla ya suele haber una versión ligera.
- Se miran cuatro cosas: código y arquitectura, seguridad y cumplimiento, propiedad intelectual y equipo y procesos.
- Los hallazgos rara vez tumban la operación del todo: lo normal es que ajusten el precio o metan condiciones. Ese es justo el daño que se evita preparándola.
- Se prepara con dos o tres meses de margen. Improvisar la semana antes es la peor de las opciones.
Qué es exactamente una due diligence técnica
La diligencia debida es el proceso de comprobación que hace un inversor —o un comprador— antes de cerrar una operación: verificar que lo que le han contado es cierto. La versión técnica se centra en el activo que en una startup de software lo es casi todo: el producto y el código que lo sostiene.
La ejecuta un técnico de confianza del fondo: un partner con perfil de ingeniería, un CTO de otra participada o una consultora especializada. Suele combinar tres cosas: acceso de lectura al repositorio, una o varias sesiones con tu equipo técnico y un cuestionario documental. Dura entre una y tres semanas.
Y no está buscando código perfecto. Nadie espera eso de una startup que ha corrido para llegar aquí. Está buscando riesgos que le cuesten dinero después: cosas que impidan escalar, que expongan a la empresa legalmente o que hagan que el producto dependa de una sola persona.
Qué miran de verdad
1. Código y arquitectura
No cuentan las líneas ni juzgan tu estilo. Evalúan si lo que tienes aguanta el crecimiento que estás prometiendo en el pitch. Si vendes multiplicar por diez los clientes y tu arquitectura tiene un cuello de botella evidente en la base de datos, la contradicción entre el plan y la realidad técnica es exactamente lo que buscan.
Miran deuda técnica y si está identificada, cobertura de tests, capacidad de desplegar sin drama, y si el sistema es entendible por alguien que llegue nuevo. Un código mediocre pero consciente —con la deuda documentada y un plan— puntúa mejor que un código mediocre que el equipo cree excelente.
2. Seguridad y cumplimiento
Aquí los hallazgos son binarios y duelen. Credenciales subidas al repositorio, datos personales sin cifrar, dependencias con vulnerabilidades conocidas sin parchear, ausencia total de control de accesos. Si tratas datos personales, además entra el RGPD: si no puedes explicar dónde están los datos de tus usuarios y quién accede a ellos, tienes un problema que no es técnico, es legal. El OWASP Top Ten es una buena lista para autoevaluarte antes de que lo haga otro.
3. Propiedad intelectual: el que más operaciones estropea
La pregunta que hace todo inversor: ¿es tuyo el código? Suena absurda hasta que se revisa, y entonces aparecen las sorpresas:
- Freelances y agencias sin cesión de derechos por escrito. En España, si no hay contrato que ceda expresamente los derechos de explotación, la posición por defecto no te favorece. Si tu MVP lo hizo una agencia con un contrato de dos páginas, revísalo hoy.
- Founders que escribieron código mientras trabajaban en otra empresa. Con equipo corporativo o en horario laboral. El antiguo empleador puede tener algo que decir.
- Licencias open source incompatibles. Usar una librería copyleft fuerte (tipo GPL) dentro de un producto propietario puede obligarte a liberar tu código. Es raro, pero cuando aparece es grave.
- Cuentas y dominios a nombre de una persona, no de la sociedad. Los repositorios, el cloud y el dominio deben pertenecer a la empresa.
4. Equipo y procesos
El riesgo que más miedo da a un fondo se llama bus factor: cuánta gente tendría que irse para que el producto se vuelva inmantenible. Si la respuesta es «una», eso es un descuento en la valoración. También miran cómo priorizáis, cómo desplegáis y si el conocimiento está en la cabeza de alguien o escrito en algún sitio.
Qué encuentran casi siempre (y cuánto cuesta arreglarlo)
| Hallazgo | Gravedad para el fondo | ¿Da tiempo a arreglarlo? |
|---|---|---|
| Secretos o credenciales en el repositorio | Alta — señal de higiene mínima | Sí, en días |
| Sin cesión de derechos de una agencia o freelance | Muy alta — puede bloquear el cierre | Depende de que el tercero coopere. Empieza ya |
| Cobertura de tests casi nula | Media — pero contradice cualquier plan de escalar | Parcialmente: cubre primero lo crítico |
| Todo el conocimiento en un solo desarrollador | Alta — riesgo de continuidad | Sí: documentar y repartir en semanas |
| Deuda técnica alta pero identificada y con plan | Baja — se acepta como normal | No hace falta: basta con demostrar que la conoces |
| Factura de cloud desproporcionada al uso | Media — afecta a los unit economics | Sí, y suele pagarse solo |
Fíjate en el patrón: lo que se penaliza no es tener problemas, es no saber que los tienes. Un equipo que llega con su propia lista de deuda técnica, priorizada y con plazos, transmite madurez. Un equipo al que le descubren los problemas transmite lo contrario —y a partir de ahí el fondo se pregunta qué más no sabes.
Cómo prepararla: los tres meses previos
- Audítate tú primero. Con tres meses de margen, haz que alguien externo revise el código, la arquitectura y la seguridad con los mismos ojos que va a usar el fondo. Es exactamente lo que hacemos en una auditoría de software: encontrar lo que otro va a encontrar, pero cuando todavía te da tiempo a reaccionar.
- Cierra el capítulo de propiedad intelectual. Reúne todos los contratos de desarrollo (empleados, freelances, agencias) y comprueba que hay cesión expresa de derechos. Pasa los repositorios, el cloud y los dominios a titularidad de la sociedad. Revisa las licencias de tus dependencias. Esto es lo primero que hay que empezar, porque es lo único que depende de terceros.
- Arregla lo barato y visible. Rota credenciales y sácalas del código. Parchea las vulnerabilidades conocidas de tus dependencias. Pon tests a la ruta crítica del producto. Son semanas de trabajo que evitan los hallazgos más embarazosos.
- Documenta lo que no da tiempo a arreglar. No todo se arregla, y no pasa nada. Escribe un documento honesto de deuda técnica: qué hay, por qué se hizo así, qué riesgo tiene y cuándo pensáis abordarlo. Entregarlo tú, antes de que pregunten, cambia la conversación entera.
- Prepara el data room técnico y ensaya. Diagrama de arquitectura, stack, entornos, política de despliegue, plan de continuidad, organigrama técnico. Y ensaya la sesión: quién responde qué, y qué se contesta cuando la respuesta es «eso lo hicimos rápido y lo sabemos».
Y si no tienes a nadie técnico que lidere esto
Es la situación más común en startups cuyos fundadores vienen de negocio: el desarrollo lo lleva una agencia o un par de programadores, y de repente hay que sentar a alguien delante de un partner técnico a defender decisiones de arquitectura. No es un problema de esfuerzo, es de criterio: necesitas a alguien que sepa qué van a preguntar y qué contestar.
Es uno de los encargos típicos de un CTO as a Service: hacemos primero de auditor incómodo —encontrar lo que el fondo va a encontrar— y después de interlocutor técnico en las sesiones con el inversor. Si el concepto te suena nuevo, lo explicamos a fondo en qué es un CTO externo y cuándo tu empresa lo necesita. Y si el problema de fondo es que dependéis de un proveedor al que nadie supervisa, empieza por aprender a supervisar a la agencia que te desarrolla el software.
El objetivo de preparar una due diligence técnica no es que no encuentren nada. Es que no encuentren nada que tú no supieras ya.
¿Tienes una ronda delante y la parte técnica sin revisar?
Auditamos tu código, tu arquitectura y tu propiedad intelectual antes de que lo haga el fondo, y te acompañamos en las sesiones técnicas. Presupuesto cerrado y respuesta en 24 h.
Hablemos de tu negocio →