Una checklist solo sirve si cada punto lleva una consecuencia adjunta. Esta está ordenada por lo que de verdad cambia un acuerdo.
Propiedad y dependencias
Producto y operaciones
Corrección y decisión
Úsala como documento de trabajo durante la diligencia. Cada sección indica qué solicitar, qué verificar y —lo esencial— qué significa comercialmente una mala respuesta. Los puntos están ordenados por coste de equivocarse, no por comodidad de comprobación.
Antes de empezar: qué solicitar
- Acceso de lectura a todos los repositorios, incluida la infraestructura como código
- Historial completo de commits (no una instantánea aplastada — el historial revela quién construyó esto de verdad y a qué velocidad)
- Recorrido por la arquitectura con el ingeniero que la construyó, 1-2 horas
- Acceso al gestor de incidencias y a cualquier registro de incidentes
- Lista de servicios de terceros y sus condiciones contractuales
- Contratos de colaboradores y documentos de cesión de PI
Sección 1 — Integridad del dinero y los datos (nivel acuerdo)
| Comprobación | Una mala respuesta significa |
|---|---|
| ¿Saldos derivados de un libro mayor append-only? | El dinero puede estar mal en silencio y ser irrecuperable — financiar remediación o retirarse |
| ¿Claves de idempotencia en cada ruta de pago? | Los reintentos pueden cobrar dos veces; puede haber pérdidas ya existentes sin detectar |
| ¿Dinero guardado como enteros en unidades menores? | La aritmética en coma flotante acumula error en cada transacción |
| ¿Conciliación contra la liquidación del proveedor? | Las discrepancias afloran vía reclamaciones de clientes |
| ¿Rastro de auditoría inmutable incl. acciones de admin? | No se pueden responder preguntas del regulador ni disputas |
Sección 2 — Seguridad y multi-tenancy (nivel acuerdo)
- Autorización aplicada en servidor en cada petición, no ocultando elementos de interfaz
- Aislamiento multi-tenant verificado con test, no supuesto tras leer código
- Secretos en un gestor, ausentes del historial de git (revisa el historial, no solo HEAD)
- Qué datos regulados se almacenan, dónde y si hace falta
- Distancia a la certificación que exige el go-to-market (SOC 2, ISO 27001, PCI DSS)
Sección 3 — Propiedad y legal (nivel acuerdo)
- Cesión de PI firmada por cada contratista y fundador
- Revisión de licencias open source — contaminación copyleft en un producto propietario
- Código copiado de empleadores anteriores (pregúntalo directamente; ocurre)
- Dependencia de proveedor: qué se rompe si uno clave sube precios o cierra
Sección 4 — Arquitectura y escala (alto)
- Dónde se rompe el sistema bajo el crecimiento del modelo financiero — una cifra concreta, no tranquilizaciones
- El techo de la capa de datos: maestro único de escritura, consultas sin límite, cobertura de índices frente a patrones reales
- Aislamiento de fallos: ¿una dependencia lenta degenera en caída total?
- Curva de coste de infraestructura a 10× — ¿sobrevive la unit economics?
- Arquitectura acorde al tamaño del equipo (sistemas distribuidos con equipo pequeño son un coste, no un mérito)
Sección 5 — Capacidad de entrega (alto)
| Señal | Saludable | Preocupante |
|---|---|---|
| Frecuencia de despliegue | Varias veces por semana | Mensual, programada, temida |
| Tiempo de entrega de un cambio pequeño | Horas a un día | Semanas |
| Rollback | Un comando, ensayado | Nunca probado |
| Detección de incidentes | Monitorización interna | Avisos de clientes |
| Tests en rutas de dinero/auth | Presentes | Ausentes al margen de la cobertura global |
Sección 6 — Equipo y persona clave (alto)
- Bus factor de cada subsistema crítico — si alguno es 1, eso es riesgo del acuerdo y exige mitigación
- Si el conocimiento existe por escrito o solo en las cabezas
- Exposición de retención: quién sería catastrófico perder en los próximos 12 meses
- Realismo del plan de contratación que asume el roadmap
Puntuación: consecuencia, no gusto
Puntúa cada hallazgo por lo que ocurre si no se arregla, y deja que eso guíe la respuesta en el acuerdo:
- Nivel acuerdo — integridad del dinero, exposición de datos, PI poco clara. Condición de cierre o remediación financiada.
- Alto — techo de escalado por debajo del plan, dependencia de una persona, sin seguridad de despliegue. Costeado en el plan de 90 días post-cierre.
- Medio — deuda acumulativa que ralentiza la entrega. Anotar y vigilar.
- Ruido — estilo, preferencia de framework, volumen de documentación. Excluir del informe por completo.
Si un hallazgo no puede vincularse a dinero, tiempo o exposición legal, no pertenece a un memorando de inversión.
Qué exigir en el informe final
- Un resumen de una página sobre el que pueda actuar un socio no técnico
- Cada hallazgo con evidencia que el equipo del objetivo pueda verificar por su cuenta
- Estimaciones de remediación en semanas-ingeniero, para que se conviertan en dinero
- Una declaración explícita de lo que NO se examinó — para que nadie asuma una cobertura que no existió
Convertir la lista de comprobación en una decisión
Cada respuesta debe vincularse con evidencias y consecuencias para la operación. Acuerde límites, accesos y preguntas antes de recoger documentos. Separe hallazgos verificados, declaraciones de dirección y pruebas ausentes. Una casilla vacía no demuestra bajo riesgo.
| Hacer medible la decisión | Evidencias que acordar antes de empezar |
|---|---|
| Propiedad y dependencias | Solicitar historial del repositorio, acuerdos de colaboradores e inventario de dependencias. La asesoría jurídica valida los derechos. |
| Producto y operaciones | Seguir un recorrido relevante, revisar despliegue y recuperación y contrastar arquitectura con crecimiento previsto. |
| Corrección y decisión | Asignar responsable, esfuerzo, dependencias y verificación. Separar condiciones previas del plan posterior a la operación. |
El informe debe distinguir lo examinado, lo desconocido y las consecuencias. Revisar documentos no acredita por sí solo controles efectivos en producción; la revisión técnica no es una certificación jurídica.
Preguntas frecuentes
¿Qué debe incluir una checklist de due diligence técnica?
Seis áreas, por orden de consecuencia: integridad del dinero y los datos, seguridad y aislamiento de tenants, propiedad intelectual, arquitectura y margen de escalado, capacidad de entrega y riesgo de persona clave. Cada punto debe llevar una consecuencia comercial declarada — una checklist sin consecuencias produce informes sobre los que nadie actúa.
¿Cuál es el punto que más se olvida?
La cesión de PI de los contratistas. No es una pregunta técnica, así que los revisores técnicos la saltan y los legales asumen que ingeniería la cubrió. Además es lo que más tarda en arreglarse, y por eso debe comprobarse en los primeros días y no en los últimos.
¿Pueden los fundadores usar esta checklist ellos mismos?
Sí, y es buena idea antes de levantar. Los hallazgos que descubres tú se convierten en un plan de remediación que controlas; esos mismos hallazgos descubiertos por el asesor de un inversor se convierten en una posición negociadora en tu contra.
¿Prefieres que lo haga alguien que lo hace cada semana?
Entregamos diligencia con hallazgos ordenados por consecuencia de negocio y remediación valorada en semanas-ingeniero.
Para seguir leyendo
Due diligence técnica para inversores: la guía completa
La due diligence técnica no es una revisión de código. Es la respuesta a una pregunta: ¿cuánto costará llevar esta tecnología hasta donde la tesis de inversión la necesita?
Qué buscan de verdad los VC en la due diligence técnica
Los inversores no están calificando tu código. Están poniendo precio al riesgo de que la tecnología detenga el plan que están financiando — y los fundadores que lo entienden se preparan de forma muy distinta.