Una operación corporativa se decide con dos informes. El financiero cuenta lo que la empresa ha ganado; el técnico cuenta si lo que la sostiene aguanta otros cinco años. En España la parte financiera y la legal llevan décadas profesionalizadas, con metodología, plantillas y equipos dedicados. La due diligence técnica, en cambio, sigue apareciendo tarde en el calendario, con menos presupuesto del que merece y encargada muchas veces a alguien que va a «echar un vistazo al código» durante un par de tardes.
El resultado de esa asimetría lo hemos visto en primera persona más de una vez: se compra una plataforma que factura bien y, seis meses después, el comprador descubre que el 40% del código no se puede tocar sin romper la facturación, que la mitad de la infraestructura está a nombre personal de un antiguo socio, o que el producto entero depende de una librería con licencia copyleft que obliga a publicar el fuente. Ninguna de esas cosas aparece en un balance. Todas aparecen en una due diligence técnica bien hecha.
Este artículo describe cómo se ejecuta una due diligence técnica de verdad: qué se revisa, en qué orden, con qué accesos, cuánto tiempo lleva, cómo se clasifican los hallazgos y qué debe contener el informe para que sirva en una mesa de negociación y no solo en una carpeta compartida. Está escrito desde el lado de quien la ejecuta —somos la agencia a la que llaman para hacerla, y también a la que llaman para arreglar lo que aparece después— y va dirigido a fondos, family offices, direcciones de empresa que compran competencia y founders que quieren llegar a la ronda sin sorpresas.
1. Qué es exactamente una due diligence técnica (y qué no es)
Una due diligence técnica es una revisión independiente del activo tecnológico de una empresa, ejecutada con un objetivo muy concreto: cuantificar el riesgo y el coste oculto que asume quien va a invertir, comprar o fusionar. No es un ejercicio académico ni un listado de buenas prácticas incumplidas. Es una valoración con números y con consecuencias contractuales.
La diferencia práctica con una revisión ordinaria está en la pregunta que se responde. Una auditoría técnica de software convencional responde a «¿cómo mejoro esto?». Una due diligence responde a «¿cuánto me va a costar esto y qué puede impedir la operación?». La primera se entrega al equipo técnico; la segunda se entrega al comité de inversión, y por eso el informe tiene que estar escrito en un idioma que entienda alguien que no ha programado nunca, sin perder el rigor que exigirá el CTO cuando lo lea.
1.1 Lo que no es
No es un pentest. La seguridad es una de las áreas revisadas, pero una auditoría de seguridad con pruebas de intrusión tiene su propio alcance, sus permisos y su calendario; si la operación lo requiere, se contrata en paralelo y sus conclusiones se integran como un capítulo.
Tampoco es una valoración del producto ni un análisis de mercado. Que la plataforma esté bien construida no significa que se venda. La due diligence técnica dice si el activo es sólido, no si el negocio es bueno.
Y no es una foto del código a fecha de hoy. Es un análisis de trayectoria: cómo ha evolucionado el repositorio, con qué ritmo, con cuántas manos, y qué dice ese historial sobre la capacidad del equipo de seguir entregando después del cierre.
1.2 Quién la encarga y qué hace con ella
Hay tres perfiles habituales. El inversor (fondo, business angel, corporate venture) la usa para ajustar valoración y para redactar condiciones: hitos técnicos, permanencia del CTO, saneamiento de licencias antes del desembolso. El comprador industrial la usa para dimensionar la integración: cuánto cuesta meter esa plataforma en su ecosistema, si podrá unificar los ERP, si tendrá que mantener dos stacks durante años. Y el vendedor —cada vez más— la encarga sobre sí mismo (vendor due diligence) para llegar al proceso con los deberes hechos, sin que el comprador descubra nada que él no supiera ya.
Ese tercer caso es el más rentable de los tres. Un founder que sanea licencias, documenta la arquitectura y reduce su deuda técnica seis meses antes de abrir el proceso llega a la negociación sin descuentos que justificar.
2. Cuándo se hace: cinco escenarios que la justifican
La due diligence técnica no es exclusiva de las fusiones y adquisiciones. Estos son los cinco encargos que más recibimos:
Ronda de financiación. A partir de una serie A el inversor quiere saber si el equipo puede triplicar el producto sin reescribirlo. Aquí el foco está en escalabilidad y en la capacidad de entrega, no tanto en el detalle del código.
Compra o fusión. El caso clásico. Foco en titularidad, licencias, dependencia de personas y coste de integración.
Sustitución de proveedor. Una empresa lleva años con una agencia o un equipo externo y quiere cambiar. Antes de mover nada necesita saber qué recibe realmente: si el código está completo, si los accesos son suyos, si el traspaso es viable. Este escenario se parece mucho a un code review externo, pero con un capítulo entero dedicado a la transferencia de conocimiento.
Entrada de un CTO o de un equipo nuevo. Cuando llega un responsable técnico a una empresa que no tenía perfil interno, lo primero razonable es un diagnóstico independiente. Es un patrón habitual también en el trabajo de un CTO externo.
Decisión de continuidad. Una dirección duda entre seguir invirtiendo en su plataforma o migrar a un producto de mercado. La due diligence aporta el coste real de cada camino, muy en la línea del análisis de software a medida frente a SaaS.
3. Las siete áreas que se revisan
Un alcance serio cubre siete bloques. Se pueden priorizar según el tipo de operación, pero ninguno se elimina del todo: los problemas caros suelen estar precisamente en el bloque que alguien decidió saltarse por falta de tiempo.
3.1 Producto y arquitectura
Se levanta el mapa real del sistema: servicios, integraciones, flujos de datos, puntos únicos de fallo. Interesa el grado de acoplamiento (si tocar el módulo de precios obliga a desplegar el sistema entero), el modelo de datos (si soporta multi-cliente, multi-moneda o multi-país cuando el plan de negocio lo exige) y los límites duros de escalado.
La pregunta operativa es sencilla de formular y difícil de responder: si el volumen se multiplica por diez, ¿qué se rompe primero y cuánto cuesta arreglarlo? Muchas plataformas que funcionan de maravilla con 500 pedidos al día tienen un cuello de botella conocido —una consulta, un cron, un proceso de facturación secuencial— que nadie ha tocado porque todavía no molesta. Ese dato vale dinero en una negociación, y es el mismo patrón que describimos al hablar del salto del MVP al producto escalable.
3.2 Código y calidad
Aquí conviene separar la métrica del criterio. Las herramientas de análisis estático (SonarQube, PHPStan, ESLint, Psalm) dan complejidad ciclomática, duplicación, cobertura de tests y densidad de code smells. Son útiles como termómetro, pero un informe que solo enseña gráficas de Sonar no vale nada: hay bases de código con métricas mediocres perfectamente mantenibles, y otras impecables en el panel que nadie sabe modificar.
Lo que aporta valor es la lectura dirigida de los tres o cuatro módulos que sostienen el negocio —cobros, facturación, motor de cálculo, integraciones críticas— y la comparación con el historial de Git: quién ha tocado qué, con qué frecuencia, cuántas veces se ha revertido, cuántos hotfixes ha habido en producción el último año. Un módulo con veinte parches urgentes en doce meses está diciendo algo que ninguna métrica estática recoge.
3.3 Infraestructura, despliegue y operación
Inventario de entornos, proveedores, cuentas y contratos. Se comprueba si existe infraestructura como código o si el servidor se montó a mano hace seis años, si hay CI/CD o los despliegues son por FTP, si los backups existen y se han restaurado alguna vez —la diferencia entre ambas cosas es donde se hunden más empresas de las que parece—, y cuál es el coste cloud real por cliente frente al que figura en el plan financiero.
También se revisa la monitorización: qué se mide, quién recibe las alertas, cuánto se tarda en detectar una caída. Una plataforma sin observabilidad no es solo un riesgo operativo; es una señal fiable de que nadie ha tenido tiempo de hacer bien el trabajo de base.
3.4 Seguridad y cumplimiento
Revisión de gestión de accesos y secretos, cifrado en tránsito y en reposo, exposición de servicios, estado de parches y dependencias vulnerables. Si la empresa maneja datos personales, se comprueba el encaje con el RGPD: base legal, encargados de tratamiento, registro de actividades, plazos de conservación, y si ha habido brechas notificadas o —peor— no notificadas.
En operaciones con clientes corporativos o con administración pública se valora también el estado frente a marcos formales: los controles técnicos de ISO 27001, el Esquema Nacional de Seguridad o NIS2. Una plataforma que factura al sector público sin capacidad de acreditar cumplimiento tiene un riesgo comercial concreto, no teórico. Y si el producto expone integraciones, el capítulo de seguridad de APIs empresariales merece su propia revisión: las APIs olvidadas de un entorno de pruebas son una de las vías de exposición más repetidas.
3.5 Datos
Volumen, calidad, trazabilidad y —crítico— titularidad. ¿De quién son los datos que la plataforma explota? ¿Los contratos con clientes permiten migrarlos, agregarlos, usarlos para entrenar modelos? ¿Hay dependencia de una fuente externa cuyo contrato vence en catorce meses? En operaciones donde el valor está en el dato, este bloque puede pesar más que todo el análisis de código.
3.6 Equipo y conocimiento
Se mide el bus factor: cuántas personas tendrían que desaparecer para que el producto quedara sin mantenimiento viable. Se revisa la documentación existente —arquitectura, decisiones, procedimientos de despliegue y de recuperación—, el reparto real de contribuciones en el repositorio y el grado de dependencia de proveedores externos.
Aquí aparece uno de los hallazgos más habituales y más caros: un único desarrollador, muchas veces el fundador técnico, concentra el conocimiento de todo el núcleo. No es un defecto moral de nadie; es el resultado natural de crecer rápido. Pero condiciona la operación, porque obliga a negociar permanencia, a presupuestar traspaso o a asumir un riesgo con precio.
3.7 Licencias, propiedad intelectual y dependencias
Inventario completo de dependencias con su licencia (SBOM). Se buscan licencias copyleft fuertes —GPL, AGPL— incrustadas en el producto, componentes sin licencia identificable, código copiado sin atribución y librerías abandonadas sin mantenimiento desde hace años.
En paralelo, la cadena de titularidad del código: contratos con empleados y freelance con cesión expresa de derechos de explotación, acuerdos con agencias anteriores, y quién figura como titular de dominios, cuentas cloud, repositorios y certificados. Es sorprendente la frecuencia con la que un activo crítico está a nombre de una persona física que ya no trabaja en la empresa.
¿Vas a invertir, comprar o vender una plataforma?
En Keliam ejecutamos due diligence técnica con informe orientado a decisión: hallazgos clasificados, coste estimado de remediación y plan de los primeros 100 días. Trabajamos tanto para el lado comprador como para el vendedor que quiere llegar preparado al proceso.
4. Cómo se ejecuta: fases, accesos y calendario
Una due diligence técnica de una plataforma mediana se ejecuta en dos o tres semanas. Menos de eso da para un diagnóstico superficial; más de cuatro semanas rara vez aporta información nueva y sí retrasa la operación. El calendario habitual es este:
4.1 Fase 0 — Alcance y accesos (días 1-2)
Se acuerda por escrito qué entra y qué no, se firma el acuerdo de confidencialidad y se solicita el paquete de accesos: repositorios en solo lectura con historial completo, acceso de lectura a los paneles de infraestructura, documentación existente, inventario de licencias y contratos, y un interlocutor técnico designado. Sin historial de Git no hay análisis de trayectoria; sin interlocutor, el trabajo se convierte en arqueología.
Este es también el momento de definir la ventana de preguntas: cuántas horas de entrevista se conceden y con quién. Un proceso en el que el equipo técnico del target no está disponible produce informes llenos de condicionales.
4.2 Fase 1 — Lectura fría (días 3-7)
Análisis sin intervención humana: clonado de repositorios, ejecución de herramientas de análisis estático y de composición de software, extracción de métricas de historial, revisión de la documentación tal cual está y levantamiento del mapa de arquitectura a partir del código, no a partir del diagrama que alguien dibujó en 2021.
Esta fase termina con una lista de hipótesis. No con conclusiones: con preguntas concretas para contrastar. Ese matiz separa un informe útil de una acusación mal fundada.
4.3 Fase 2 — Entrevistas y contraste (días 8-11)
Sesiones con el responsable técnico, con uno o dos desarrolladores del núcleo y, si existe, con la persona de sistemas. Se contrastan las hipótesis, se pregunta por las decisiones históricas —casi siempre hay una razón detrás de lo que desde fuera parece un disparate— y se pide que reproduzcan en vivo un despliegue y una restauración de backup.
La restauración en vivo es, con diferencia, la prueba que más sorpresas produce. Muchos equipos tienen copias; bastantes menos han comprobado que se pueden recuperar.
4.4 Fase 3 — Pruebas dirigidas (días 10-14)
Verificación práctica de los puntos críticos: pruebas de carga sobre los flujos de negocio principales, revisión manual de los módulos sensibles, comprobación de configuraciones de seguridad y, si el alcance lo incluye, pruebas de intrusión en un entorno acordado. Si el rendimiento es una preocupación central de la operación, se aplica la misma metodología que en una auditoría de rendimiento web, con métricas antes y después de cada hipótesis.
4.5 Fase 4 — Informe y sesión de contraste (días 15-18)
Redacción, valoración económica de la remediación y presentación. El informe se entrega siempre con una sesión de discusión: quien decide necesita poder preguntar, y quien ha sido auditado tiene derecho a rebatir. Un informe que se envía por correo sin defensa oral genera desconfianza y suele acabar guardado en un cajón.
5. Qué se hace con los hallazgos: la clasificación importa más que la lista
El error más común de un informe técnico dirigido a no técnicos es entregar sesenta hallazgos ordenados por severidad genérica. En una operación, la severidad relevante no es «crítica/alta/media»: es qué efecto tiene sobre el acuerdo. Nosotros usamos tres categorías.
Bloqueante. Impide o retrasa el cierre hasta que se resuelve. Titularidad del código no acreditada, licencia copyleft en el núcleo del producto, una brecha de datos personales no notificada a la autoridad, o una dependencia crítica de una persona que ya ha anunciado que se va. No se negocian con descuento: se resuelven antes de firmar o se convierten en condición suspensiva.
Ajuste de precio. Tiene coste medible y se lleva a la mesa con una cifra. Reescritura de un módulo, migración forzosa de una versión sin soporte, coste cloud muy por encima del declarado, deuda técnica cuantificada en meses-persona. Aquí el informe debe dar horizontes, no adjetivos: «entre 4 y 6 meses de dos desarrolladores» es útil; «el código necesita mejoras importantes» no lo es.
Plan post-cierre. Se asume conscientemente y se planifica. Falta de tests, documentación incompleta, monitorización pobre, despliegues manuales. Nada de esto tumba una operación, pero todo esto consume los primeros meses del equipo si no se presupuesta.
6. Los hallazgos que más se repiten
Después de bastantes procesos, la lista de sorpresas es sorprendentemente estable:
Activos a nombre equivocado. Dominios, cuentas de AWS o Google Cloud, certificados SSL, cuentas de pasarelas de pago y repositorios registrados a título personal de un fundador, un antiguo empleado o incluso de la agencia que hizo la primera versión. Barato de arreglar, caro de descubrir tarde.
Licencias sin revisar. Una AGPL en el núcleo del producto obliga a publicar el código fuente de todo lo que se distribuya como servicio. Es el hallazgo que más veces ha convertido una operación cerrada en una renegociación.
Entornos que no se parecen. Producción y desarrollo con versiones distintas de lenguaje, base de datos o extensiones. Significa que nada de lo que se prueba garantiza nada, y que cada despliegue es una apuesta.
Cero trazabilidad de cambios en producción. Modificaciones directas sobre el servidor sin pasar por control de versiones. Cuando aparece, el repositorio deja de ser una fuente fiable y el análisis hay que rehacerlo contra la máquina real.
Seguridad delegada en el hosting. «Eso lo lleva el proveedor» suele significar que nadie lo lleva. La revisión de desarrollo seguro según ISO 27001 y el ENS deja rápidamente en evidencia si existe un ciclo real de control o solo una expectativa.
Contratos de cliente con cláusulas técnicas imposibles. SLAs de disponibilidad del 99,99% en una plataforma monolítica con un solo servidor, o compromisos de portabilidad de datos que el sistema no puede cumplir. Es riesgo contractual puro, y casi nunca lo ha leído nadie del lado técnico.
7. El entregable: qué debe contener el informe
Un informe de due diligence técnica que sirva para decidir tiene, como mínimo, estas piezas:
Resumen ejecutivo de dos páginas con el veredicto, los tres riesgos principales y la cifra estimada de remediación. Si el comité solo lee esto, tiene que poder decidir.
Mapa de arquitectura real reconstruido durante el análisis, no el que entregó la empresa. Suele ser el documento más valioso del paquete y, con frecuencia, el primero que el propio equipo del target no tenía.
Tabla de hallazgos con identificador, área, descripción, evidencia, clasificación (bloqueante / ajuste / post-cierre), esfuerzo estimado y responsable propuesto. Con evidencia significa con referencia al fichero, al commit o a la captura: un hallazgo sin prueba es una opinión.
Valoración económica por rangos y por escenarios. Rangos porque una estimación puntual en este contexto es falsa precisión; escenarios porque el coste de «mantener» y el de «escalar x10» no tienen nada que ver.
Plan de 100 días con las acciones ordenadas por dependencia y no por severidad. Es el capítulo que convierte un diagnóstico en algo accionable.
Anexos técnicos con salidas de herramientas, SBOM completo e inventario de accesos. Nadie los lee en la primera vuelta y todos los agradecen en la segunda.
8. Del informe al plan: los primeros 100 días
Una due diligence que termina en el cierre de la operación se ha desaprovechado a medias. El mismo trabajo que ha servido para negociar sirve para arrancar, y el momento de máxima capacidad de cambio en una empresa adquirida son las primeras semanas.
Un plan de 100 días razonable se ordena así. Semanas 1-2: cerrar los bloqueantes formales que quedaran pendientes —titularidad de activos, accesos, contratos de cesión— y establecer inventario y control de accesos. Semanas 3-6: tapar los agujeros de operación: backups verificados con restauración real, monitorización con alertas que llegan a alguien, y pipeline de despliegue reproducible. Semanas 7-12: reducir el riesgo de conocimiento con documentación de arquitectura, pairing sobre los módulos críticos y, si procede, incorporación de un segundo perfil con acceso al núcleo. Semanas 13-14: revisión y replanificación con datos nuevos.
Fíjate en lo que no está en la lista: reescribir. La tentación de empezar de cero es fortísima cuando se hereda código ajeno, y casi siempre es la decisión equivocada en el primer trimestre. Primero se estabiliza, se mide y se entiende; después se decide qué se reescribe, con criterio de negocio y con la deuda ya cuantificada.
9. Errores frecuentes al encargar una due diligence técnica
Encargarla demasiado tarde. Si el informe llega la semana anterior a la firma, no hay margen para renegociar ni para resolver bloqueantes. Debe empezar en cuanto hay carta de intenciones.
Dar solo cinco días. Un alcance de tres semanas comprimido en cinco días produce un documento de apariencia profesional y valor real escaso. Si no hay tiempo, es mejor reducir el alcance por escrito que fingir que se ha cubierto todo.
Encargársela a quien va a mantener la plataforma después. El conflicto de interés es evidente: quien aspira al contrato de mantenimiento tiene incentivos para inflar los hallazgos, y quien la construyó los tiene para minimizarlos. La independencia no es una formalidad.
Pedir solo «revisión de código». El código es una de las siete áreas y rara vez es donde está el problema caro. Las licencias, la titularidad y el bus factor tumban más operaciones que la complejidad ciclomática.
No involucrar al equipo del target. Un análisis hostil, sin entrevistas, produce conclusiones injustas y además envenena la relación con las personas que hay que retener después del cierre.
Confundir el informe con una sentencia. Casi ningún sistema real pasa una due diligence sin hallazgos. El objetivo no es aprobar o suspender: es saber exactamente qué se compra y a qué precio.
Conclusión
La due diligence técnica es el instrumento que traduce la tecnología a un lenguaje que la mesa de negociación entiende: riesgo, coste y plazo. Bien ejecutada, no ralentiza la operación —la ordena—, y deja además dos entregables que sobreviven al cierre: el mapa real del sistema y un plan de los primeros 100 días que evita que el equipo nuevo se pase el primer trimestre descubriendo cosas.
Si estás del lado comprador, exígela con alcance completo y tiempo suficiente. Si estás del lado vendedor, adelántate: los seis meses previos a abrir un proceso son la inversión con mejor retorno que puedes hacer sobre tu propio activo técnico. Y en ambos casos, pide que el informe clasifique cada hallazgo por su efecto sobre el acuerdo, no solo por su gravedad técnica. Esa diferencia es la que hace que un documento sirva para decidir.
Preguntas frecuentes sobre la due diligence técnica
¿Cuánto cuesta una due diligence técnica?
Depende del alcance y del tamaño de la plataforma, pero el orden de magnitud habitual para una empresa mediana es el de dos a cuatro semanas de un equipo pequeño y sénior. Frente al importe de la operación suele ser una fracción muy pequeña, y frente al coste de un hallazgo descubierto seis meses después no admite comparación.
¿Se puede hacer sin acceso al código?
Se puede hacer una revisión parcial —arquitectura declarada, infraestructura, procesos, entrevistas— pero no es una due diligence técnica completa. Si el vendedor no concede acceso de lectura al repositorio, eso en sí mismo es un dato que el informe debe recoger de forma explícita.
¿Qué diferencia hay entre due diligence técnica y auditoría técnica?
El destinatario y la finalidad. La auditoría técnica busca mejorar el sistema y se dirige al equipo; la due diligence busca cuantificar riesgo para una decisión de inversión o compra y se dirige a quien decide. La metodología de análisis se solapa mucho; la forma de presentar los resultados, nada.
¿Cuánto tiempo tarda?
Entre dos y cuatro semanas para una plataforma mediana, contando desde la entrega efectiva de accesos. Los procesos que se alargan más allá suelen estar bloqueados por falta de accesos o de disponibilidad del equipo técnico, no por el análisis.
¿Sirve también si no hay operación a la vista?
Sí. Muchas empresas la usan como diagnóstico de continuidad antes de decidir si siguen invirtiendo en su plataforma, al cambiar de proveedor o al incorporar un responsable técnico nuevo. El informe es el mismo; lo que cambia es qué se hace con él.
