La due diligence técnica es la revisión que un inversor, un comprador o un consejo encarga antes de una ronda de financiación o una venta para comprobar que el software y el equipo de ingeniería de una empresa pueden sostener el plan para el que es el dinero: arquitectura, seguridad y protección de datos, calidad del código, infraestructura, proceso de entrega, documentación, las personas de las que depende y las licencias sobre las que se construye. Cloudnonic trabaja en los dos lados. A los fundadores que preparan una ronda les dejamos la ingeniería lista para que la revisión sea un ejercicio de lectura, con documentación producida durante el desarrollo y no escrita la semana anterior. Para inversores y compradores, hacemos la evaluación como ingenieros senior independientes e informamos de lo que la plataforma puede sostener y de lo que no.
Las ocho áreas que recorre el asesor técnico de un inversor y lo que cada una tiene que demostrar. La misma lista es nuestra checklist cuando preparamos a una empresa y la estructura de nuestro informe cuando evaluamos una.
Si la estructura del sistema encaja con los próximos tres años del plan: multiinquilino, fronteras entre servicios, las partes que tendrán que escalar y el registro de por qué se construyó así.
Control de acceso, cifrado, trazas de auditoría, residencia de datos y gestión del consentimiento, escritos como conceptos y alineados con la regulación bajo la que opera el negocio.
Código legible con un proceso de revisión, pruebas automatizadas que corren en el pipeline y dependencias actualizadas y escaneadas.
Quién es dueño de las cuentas cloud, si la infraestructura está definida como código, cuánto cuesta al mes y por cliente, y cuándo se probó por última vez la recuperación y cuánto tardó.
Cómo viaja un cambio del ticket a producción: revisión, staging, aprobación, marcha atrás y cadencia de releases, con la evidencia de que ocurre así.
Registros de decisiones de arquitectura, runbooks, notas de incorporación y un modelo de datos que un ingeniero nuevo, o un revisor, pueda leer sin una reunión.
Qué pasa cuando se va el único ingeniero que conoce el despliegue, y si ese conocimiento está en el repositorio o en una cabeza.
Licencias open source en el árbol de dependencias, propiedad del código escrito por contratistas y agencias, y las condiciones de terceros de las que depende el producto.
GoMedicus pasó de un taller de alcance en enero de 2025 a una Serie A firmada en agosto de 2026. Cuando se levantó la ronda, la plataforma superó una due diligence técnica sobre la documentación que el equipo de ingeniería había producido mientras construía: decisiones de arquitectura, conceptos de seguridad y protección de datos, documentación de procesos. Cloudnonic sigue siendo el equipo de ingeniería de la plataforma.
NestJS
Next.js
PostgreSQL
AWS
Terraform
Una preparación funciona como un proyecto integrado: uno o dos ingenieros senior dentro de tus repositorios, cuentas cloud y pipelines durante un periodo acotado, trabajando con quien hoy es responsable del sistema, tu propio equipo o la agencia que lo construyó. Necesitamos acceso de lectura al código y a la infraestructura, una hora con las personas que lo construyeron y el plan en el que se basa la ronda. Una evaluación para un inversor se delimita desde el data room, se hace bajo NDA y se reporta al inversor, compartiendo los hallazgos con el equipo de la empresa al final. Todo lo que vemos queda bajo la confidencialidad que las partes acordaron, y no evaluamos empresas cuya ingeniería es nuestra.
Un equipo integrado · Lo que evita: Un ciclo de contratación de seis meses para una especialidad que necesitas este trimestre, y un proveedor que trabaja fuera de tu proceso y no deja rastro en tus repositorios.
Los dos modelos de colaboración →Elegido por proyecto. Escogemos lo que tu equipo pueda operar después de nosotros, no lo que está de moda.
OpenAPITerraform
GitHub ActionsGitHub ActionsTerraformOpenAPISe abre el data room, no hay nada escrito, y el equipo pasa las semanas previas a la ronda produciendo diagramas de arquitectura y políticas de seguridad de memoria en vez de entregar.
Una revisión que se lee como reconstruida, una ronda retrasada y un equipo que dejó de entregar durante el mes más visible de la vida de la empresa.
La documentación se produce durante el desarrollo: las decisiones de arquitectura se registran cuando se toman, los conceptos de seguridad se escriben con la funcionalidad, el proceso lo documenta el pipeline que lo ejecuta. El paquete es un subproducto, no un proyecto.
El despliegue, los secretos y el procedimiento de recuperación viven con un ingeniero, a menudo un contratista, y el revisor pregunta qué pasa cuando esa persona se va.
Un hallazgo de persona clave que se lee como un riesgo para toda la inversión, y una prima de retención negociada bajo presión.
Infraestructura como código, runbooks en el repositorio, un procedimiento de recuperación ejecutado en un simulacro y una segunda persona que lo ha ejecutado. El riesgo de persona clave es un problema de propiedad y documentación, y así lo tratamos.
La seguridad es un documento que se responde para el revisor y no una propiedad del sistema, y la primera lectura del código o el primer test de penetración encuentra la distancia entre ambos.
Hallazgos que exigen cambios de arquitectura con la ronda abierta, y un problema de credibilidad que dura más que la corrección.
El control de acceso, el registro de auditoría, el cifrado y la residencia de datos son decisiones de arquitectura, documentadas cuando se toman y demostrables en el código y en la cuenta cloud, no en una hoja de cálculo.
La revisión del inversor en sí suele durar de dos a cuatro semanas desde el acceso al data room hasta el informe. La preparación depende del estado de la documentación: un equipo que ha registrado sus decisiones necesita días para montar el paquete; una plataforma sin nada escrito necesita de cuatro a ocho semanas, la mayor parte cerrando brechas y no escribiendo. Una evaluación que hacemos para un inversor se entrega normalmente en menos de tres semanas.
Sí, y es el caso habitual. Revisamos el código, la infraestructura y la documentación tal como están, trabajamos con la agencia o los ingenieros que lo construyeron cuando siguen disponibles, y registramos lo que encontramos sin reescribir nada porque sí. La lista de brechas dice qué merece la pena corregir antes de la ronda y qué puede esperar.
Sí, como ingenieros senior independientes bajo NDA, con un informe escrito sobre arquitectura, seguridad, infraestructura, proceso de entrega y riesgo de equipo, medido contra el plan en el que se basa la ronda. No evaluamos empresas cuya ingeniería es nuestra; en esas estamos del lado del fundador y lo decimos.
Acceso de lectura a los repositorios y a las cuentas cloud, la documentación existente por incompleta que sea, el plan o el deck en el que se basa la ronda y una hora con las personas que construyeron el sistema. Firmamos un NDA antes de nada.
No. Una due diligence técnica es más amplia: juzga si toda la plataforma y el equipo pueden sostener el plan de inversión, y la seguridad es una de sus ocho áreas. Si el revisor o el plan piden un test de penetración, lo delimitamos con un socio especializado e incluimos el resultado en el paquete.
Todos los servicios de esta página se entregan con nuestro proceso AI-Native: especificaciones como fuente de verdad, agentes en el pipeline y un ingeniero con nombre que aprueba en staging.
Cómo construimos con IA →