Startups e inversores
Due diligence técnica de startups para inversores
La due diligence técnica le dice al inversor si la tecnología de una startup aguanta lo que promete el pitch: si escala, si es suya, si es segura y si depende de una sola persona.
Respuesta corta
Una due diligence técnica es la revisión independiente de la tecnología de una empresa antes de invertir en ella o comprarla. Analiza código, arquitectura, seguridad, propiedad intelectual, deuda técnica y equipo, y termina en un informe con los riesgos clasificados por gravedad y lo que costaría, a grandes rasgos, corregirlos.
¿Qué se revisa?
Se revisan la calidad del código y si la arquitectura aguanta el crecimiento, la seguridad, las dependencias de proveedores o personas clave y si lo construido coincide con lo que cuenta el pitch.
Código y arquitectura
Calidad, pruebas automáticas, documentación y si el diseño soporta el crecimiento previsto.
Seguridad
Gestión de accesos, cifrado, copias y vulnerabilidades conocidas en las dependencias.
Dependencias críticas
Proveedores, APIs o personas sin los que el producto deja de funcionar.
Coherencia con el pitch
Si lo que existe coincide con lo que se ha presentado como hecho.
¿Qué recibe el inversor?
El inversor recibe una página con la conclusión y los riesgos principales, el detalle de cada hallazgo con evidencia, gravedad y recomendación, y los puntos que conviene exigir antes o después del cierre.
Informe ejecutivo
Una página con la conclusión y los riesgos principales.
Detalle técnico
Cada hallazgo con su evidencia, gravedad y recomendación.
Condiciones sugeridas
Puntos que puede pedir resolver antes o después del cierre.
¿Cómo transcurre una due diligence técnica paso a paso?
Una due diligence técnica sigue un orden fijo que empieza con la confidencialidad y termina con una reunión para comentar el informe. Las fases habituales son estas:
- Acuerdo y alcance. Se firma la confidencialidad y se pacta qué se revisa: producto completo, un módulo o solo seguridad.
- Petición de información. La startup recibe una lista cerrada: repositorios, diagramas, proveedores, contratos de desarrollo y accesos de lectura.
- Entrevistas. Una o dos sesiones con el responsable técnico para entender decisiones y deuda conocida.
- Análisis. Revisión del código, de las dependencias y de la infraestructura, con herramientas automáticas y lectura manual.
- Informe y reunión. Se presenta al inversor y, si lo autoriza, se comparte con la startup para que pueda responder.
Si la startup ha hecho antes una preparación de la due diligence, los pasos dos y tres se acortan mucho.
Señales de alarma frecuentes en startups de fase temprana
En una startup joven, los riesgos técnicos que más pesan rara vez son de rendimiento. Suelen estar en quién controla el producto y cuánto depende de una sola pieza. Estas son las señales que conviene mirar con más calma:
- Todo el conocimiento está en la cabeza de un único programador sin documentación.
- El producto se apoya en la API de un tercero que podría cambiar precios o condiciones.
- No hay copias de seguridad probadas ni separación entre pruebas y producción.
- La parte de IA que se presenta como propia es una llamada directa a un modelo comercial sin nada encima.
- El código heredado de una agencia nunca se ha revisado desde dentro.
Ninguna de ellas descarta una inversión por sí sola. Lo que hace el informe es estimar cuánto costaría corregirlas y si conviene ponerlas como condición, a menudo con un CTO externalizado que lidere la corrección.
Ejemplo: revisión de un SaaS antes de una ronda semilla
Supón un fondo que va a entrar en un SaaS de gestión para clínicas dentales con unos cientos de clientes de pago. El deck habla de una plataforma escalable con IA propia para leer radiografías.
La revisión podría encontrar que la aplicación principal está bien construida, con pruebas y despliegues automatizados, pero que la lectura de radiografías es un prototipo que solo funciona en una demo. También que los datos de salud están alojados en un proveedor sin contrato de encargado de tratamiento firmado.
Con eso, el inversor no tiene por qué renunciar a la operación. Puede pedir el contrato firmado antes del cierre, ajustar la valoración a lo que de verdad existe y fijar un hito para la parte de IA. Para operaciones con software muy antiguo, el análisis se completa con un plan de rescate de software antiguo.
Preguntas frecuentes
¿Cuánto dura una due diligence técnica?
Depende del tamaño del producto y de lo rápido que la startup dé acceso; en una empresa en fase temprana suele ser cuestión de pocas semanas.
¿Necesitáis acceso al código fuente de la startup?
Sí, en modo lectura y con un acuerdo de confidencialidad firmado con la startup y con el inversor.
¿Hacéis due diligence técnica en compras de empresas que no son startups?
Sí, también en adquisiciones de negocios que dependen de un software propio.
¿Qué información debe preparar la startup para la revisión técnica?
Acceso de lectura a los repositorios, un esquema de la arquitectura, la lista de proveedores y servicios en la nube, los contratos con quien haya programado y una cuenta de prueba del producto. Si algo no existe, basta con decirlo: la ausencia también es un dato útil para el informe.
¿El informe de due diligence técnica puede compartirse con otros coinversores?
Sí, si el inversor que lo encarga lo autoriza y la startup no se opone por confidencialidad. En rondas sindicadas es habitual que un solo informe sirva a todos los participantes, lo que ahorra a la startup responder varias veces a las mismas preguntas.
¿En qué se diferencia una due diligence técnica de una auditoría de seguridad?
La auditoría de seguridad busca vulnerabilidades concretas, a veces con pruebas de intrusión. La due diligence técnica es más amplia: mira además arquitectura, propiedad del código, equipo, dependencias y coherencia con el pitch, y traduce todo a riesgo para la inversión.