Technical due diligence: la guía de preparación del founder no técnico

El email llega un martes por la tarde. El lead investor de tu Serie A está “casi listo” y ha contratado una firma de technical due diligence. El equipo de TDD necesitará acceso de lectura al repositorio, una call de 60 minutos con quien lleva el build y una lista de cada servicio de terceros del que depende el producto. El kickoff es el lunes. Reenvías el email a tu único desarrollador y te sientas con la pregunta que cada founder no técnico aprende a temer en el primer día de una ronda real: qué es exactamente lo que está a punto de pasarle a mi empresa.

Technical due diligence es una auditoría independiente del software, la infraestructura y las prácticas de ingeniería de una empresa, contratada por un inversor o comprador antes de comprometer capital. Existe para responder a una sola pregunta: ¿el producto que la empresa vende coincide con la realidad de ingeniería detrás de él? La auditoría cubre calidad de código, arquitectura, seguridad, capacidad del equipo y la disciplina operativa que sostiene todo el stack. Para un founder no técnico, es la primera vez que alguien de fuera con una linterna entra a mirar dentro de la caja.

Esta es la guía del founder para esa auditoría. Lo que los inversores realmente miran, las siete red flags que tumban deals y un playbook de cuatro semanas de preparación que arregla la mayoría.

Qué es technical due diligence en la práctica

La definición de manual cabe en una frase: technical due diligence es la revisión estructurada que un comprador encarga para confirmar que aquello que está comprando o financiando se sostiene técnicamente. El comprador suele ser un fondo de venture capital en Serie A o B, un comprador estratégico en M&A, un fondo de private equity en un growth deal, u ocasionalmente un cliente enterprise a punto de firmar un contrato lo bastante grande como para justificar el trabajo.

La auditoría dura de una a cuatro semanas. Involucra un equipo pequeño (en general dos a cuatro ingenieros de una firma especializada como Snyk, MEV, TechCXO o una boutique como Quandary Peak) corriendo un playbook fijo: code review, entrevista de arquitectura, scan de seguridad, entrevistas con el equipo y un informe escrito que se entrega al comprador. El informe no llega a la empresa auditada salvo que esta lo pida. El comprador lo lee a solas y decide qué hacer con los hallazgos.

Dos términos se usan de forma intercambiable y conviene desambiguarlos de una vez. Technical due diligence y technology due diligence son, en la práctica, lo mismo. Algunas firmas prefieren un término; el entregable es idéntico. En construcción y real estate, TDD se refiere a un proceso completamente distinto (auditoría estructural de un edificio). Si un resultado de búsqueda sobre el tema no menciona software, no es el documento que estás buscando.

Por qué te está pasando ahora

La TDD aparece en cuatro momentos concretos en la vida de una empresa, y el detonante suele indicar en qué se centrará la auditoría.

El primero es una ronda Serie A. El lead ha leído el deck, ha visto la demo y ahora está estresando si el producto aguanta diez veces la carga que tiene hoy. La TDD aquí es forward-looking: ¿este equipo de ingeniería puede entregar realmente el roadmap del slide?

El segundo es M&A. O un comprador estratégico quiere absorber la empresa, o un private equity quiere una posición de control. Esta TDD se centra en riesgo. El comprador paga un múltiplo de ingresos y necesita asegurarse de que no está comprando también un pasivo técnico del tamaño del precio.

El tercero es una ronda late seed o estratégica en la que un inversor sofisticado (Tiger, Sequoia, un brazo de corporate venture de primer nivel) hace una TDD ligera como parte del proceso de convicción. Es más corta, suele ser solo un code review y una call de arquitectura, y tiende a ser informal.

El cuarto, y el que la mayoría de founders no ve venir, es el cliente flagship. Un banco, una red hospitalaria, una telco grande: cualquier contrato lo bastante grande como para justificar al equipo legal del comprador acaba incluyendo una cláusula que exige una TDD antes de que el contrato entre en vigor. Hemos visto esto golpear a empresas pre-Serie A que pensaban que su primera auditoría real llegaría dentro de doce meses.

Sea cual sea el escenario, el trabajo es el mismo. Lo que cambia es el listón.

Las cuatro áreas que los auditores realmente investigan

Quítale las marcas a las consultoras y todo informe de TDD cubre las mismas cuatro áreas. La PAA favorita “cuáles son los 4 componentes de la due diligence” (financiero, operacional, legal, RH) es la lista equivocada para software; esa es la due diligence corporativa general. La versión técnica se divide así.

1. Código y arquitectura

El equipo de auditoría va a clonar tu repositorio y leerlo. No todo. Van a muestrear por directorio y por reciencia: qué se cambió la semana pasada, qué parece la lógica de dominio central, qué dice el informe de test coverage. Buscan señal en tres cosas: el código es consistente (parece que lo escribió un equipo, o cinco contratados a lo largo de tres años), la arquitectura es coherente (las fronteras entre módulos tienen sentido, o todo se ha fundido en un monolito gigante) y es mantenible (un nuevo ingeniero puede ramp up en un mes, o el bus factor es uno).

Lo que te mata aquí no es el código feo. Los auditores esperan código feo; el software siempre es más feo de lo que el founder cree. Lo que mata es la incoherencia: tres patrones distintos para el mismo problema, sin tests, sin documentación y sin historial de versionado que explique las decisiones.

2. Infraestructura y operaciones

¿Cómo corre el producto de verdad en producción? Dónde están los servidores (una cuenta de cloud real en AWS / GCP / Azure, o el Linode personal de un founder al que nadie más puede entrar), cómo es el deploy (un único comando en una pipeline de CI, o un desarrollador entrando por SSH a una máquina a las 23h), y qué pasa cuando algo se rompe (una rotación de guardias con paging, o un mensaje de Slack que nadie lee hasta la mañana siguiente).

A los auditores les importa esto porque es la dimensión más barata para comprobar si la empresa es real. Demo brillante con infraestructura frágil es el patrón de fallo más común que cazan.

3. Seguridad y compliance

¿Alguien ha corrido un scan de seguridad de verdad? ¿Los secrets están en variables de entorno o pegados en el codebase? ¿Hay audit log de quién ha accedido a datos de cliente? Si la empresa vende a sectores regulados, ¿las afirmaciones de SOC 2 / HIPAA / GDPR en la web coinciden con la realidad de ingeniería?

Es el área donde los resultados de TDD más frecuentemente tumban deals directamente. Un comprador convive con código desordenado. No convive con un hallazgo de seguridad que crea un pasivo regulatorio que heredaría al cierre.

4. Equipo y proceso

El equipo de auditoría va a entrevistar a tus desarrolladores uno a uno. Van a preguntar: cómo deciden qué construir, quién hace code review, qué pasa cuando hay un incidente en producción, y qué pasaría si tu lead engineer se fuera mañana. Las entrevistas son cortas y los auditores buscan consistencia entre lo que dice el founder y lo que dice el equipo.

Aquí es donde aparece el problema del bus factor. Si las entrevistas revelan que una sola persona es la única que entiende un sistema crítico, esa frase única va a parar al informe y los términos del deal empiezan a moverse.

Las siete red flags que tumban deals

En cada TDD que hemos acompañado con clientes, el informe del auditor tiende a girar en torno a los mismos pocos problemas. Ninguno es exótico. Todos tienen arreglo si hay aviso.

La primera es bus factor de uno. El lead engineer es la única persona que ha leído todo el codebase, y no existe documentación que sobreviva a su salida. Es el hallazgo más común y el que los inversores se toman más en serio, porque están a punto de firmar un cheque que depende de una persona que ellos no contrataron.

La segunda es ningún historial de versionado relevante. El repositorio existe, pero el primer commit es “initial commit” con 60.000 líneas volcadas de una vez. No se puede ver quién decidió qué ni cuándo. En general significa que el codebase fue migrado (típicamente desde la máquina de un freelancer anterior) y el historial se perdió. Los auditores lo señalan porque significa que la empresa no puede probar que el código es suyo.

La tercera es propiedad intelectual mal definida. El trabajo lo hizo un contratado, el contrato de desarrollo de software no incluía cláusula de work-for-hire o de cesión de IP, y ahora la empresa, técnicamente, no es dueña del código que vende. Este único hallazgo ya ha matado deals en la fase de due diligence.

La cuarta es secrets en el repositorio. API keys, contraseñas de base de datos, tokens de terceros, todo en texto plano en el codebase. Los auditores modernos corren scans automáticos de esto en la primera hora y siempre encuentran algo.

La quinta es nula observabilidad en producción. El equipo no sabe cuándo la aplicación se cae. Sin uptime monitoring, sin error tracking, sin logs que alguien lea. Cuando el auditor pregunta “¿con qué frecuencia se cae la app?”, la respuesta del equipo es “no sé, nadie se ha quejado”.

La sexta es dependencia excesiva de un único servicio de terceros. El producto, en la inspección, es una capa fina sobre la API de un proveedor. Si ese proveedor cambia el precio, deprecia el endpoint o se cae, la empresa cae con él. La auditoría cuantifica esa exposición y le pone una cifra al lado.

La séptima es deuda técnica que el equipo no sabe describir. No la existencia de deuda técnica en sí (todo producto la tiene) sino la incapacidad de señalarla. Cuando el lead engineer dice “el código está bien” pero el auditor encuentra tres migraciones a medias y un framework deprecado, la brecha entre lo que el equipo sabe y lo que realmente hay se convierte en el hallazgo que tumba el deal.

El playbook de cuatro semanas de preparación para la TDD

Si tienes cuatro semanas de aviso antes de que arranque la auditoría (y la mayoría de founders los tiene, porque el lead investor o el comprador lo señala antes del engagement formal), las siete red flags de arriba son, casi todas, arreglables. El playbook de abajo es lo que corremos con clientes que afrontan su primera TDD.

Semana uno: propiedad e inventario

Confirma por escrito que cada línea de código del repositorio fue escrita por un empleado bajo un contrato laboral estándar o por un contratado bajo un contrato de work-for-hire. Si el contrato de algún contratado no tenía cláusula de cesión de IP, envía una carta de cesión de una página y consigue la firma antes de la primera call con el auditor. Es el arreglo más barato y el que tiene el mayor downside si se ignora.

Construye un inventario de cada servicio externo del que depende el producto: cloud provider, base de datos, autenticación, pagos, email, analytics, monitoring. Una línea por servicio: qué hace, quién paga la factura, quién tiene acceso admin. El auditor va a pedir esa lista el primer día. Tenerla lista transmite profesionalidad y te ahorra una semana de emails de follow-up.

Semana dos: mata el bus factor

El problema del bus factor no se resuelve entero en dos semanas, pero sí se reduce de manera medible. Pon a tu único desarrollador en pareja con un segundo ingeniero (un junior existente, un contratado de confianza o un estudio partner) y haz que pasen la semana leyendo el codebase juntos. Escribe a mano un documento de arquitectura de una página: cuáles son los componentes principales, qué habla con qué, qué se rompe si un servicio concreto cae. Ese documento hace más por tu nota de auditoría que cien features nuevas.

Si no tienes un segundo ingeniero disponible y el deal es lo bastante grande como para justificarlo, esta es la semana de traer un technical advisor. Un ingeniero senior que ha pasado por TDDs del lado auditado puede leer tu codebase, identificar lo que va a ser flagged y, en algunos casos, co-firmar decisiones durante las entrevistas de la auditoría.

Semana tres: limpia los hallazgos obvios

Corre un scanner de secrets gratuito sobre el repositorio (el scanner nativo de GitHub caza los casos comunes). Rota cualquier clave que aparezca. Mueve cada credencial a variables de entorno o a un secrets store gestionado. Es un trabajo de dos días que evita el hallazgo automático más común.

Monta observabilidad básica. Sentry para errores, un monitor de uptime simple (Better Stack, Pingdom, o incluso una cuenta gratuita de UptimeRobot) golpeando tu URL de producción cada minuto. El objetivo no es cobertura perfecta. El objetivo es que, cuando el auditor pregunte “¿cómo sabes cuándo la app está caída?”, tengas una respuesta que no sea encogerte de hombros.

Semana cuatro: documentación y simulacro

Escribe cuatro documentos cortos: un README que explique cómo correr el proyecto localmente, un runbook de deploy que explique cómo llega una release a producción, una nota de respuesta a incidentes que explique qué hacer cuando algo se rompe y un overview de seguridad de una página que liste qué datos almacenas y cómo están protegidos. Ninguno necesita ser largo. El equipo de auditoría comprueba que existen y que son honestos, no que estén pulidos.

Haz una entrevista simulada con tu desarrollador. Hazle las preguntas que sabes que el auditor le va a hacer, en el orden en el que se las va a hacer. Graba las respuestas. La primera vez que tu único ingeniero escuche “¿qué pasaría si te fueras mañana?” no puede ser delante del auditor.

Qué pasa después del informe

El auditor entrega el informe al comprador, no a ti. En la mayoría de los casos el comprador comparte al menos un resumen con el founder durante la negociación, sobre todo si los hallazgos mueven los términos del deal. Espera tres desenlaces posibles.

Informe limpio, el deal cierra con los términos originales. Es raro en una primera auditoría y vale la pena celebrarlo cuando pasa.

Informe mixto, el deal cierra con condiciones. El comprador deja el cierre condicionado a remediación (contratar un segundo ingeniero en 60 días, completar un SOC 2 en seis meses, transferir el IP de un contratado concreto). Es el resultado más común y las condiciones son casi siempre negociables. El calendario de remediación pesa más que el hallazgo en sí.

Informe malo, el deal se renegocia o se cae. Baja el precio, se aprietan los términos o el comprador se retira. Los hallazgos que producen este desenlace casi siempre están en las categorías de IP, seguridad o bus factor. Son las siete red flags de arriba, en su peor versión.

Los founders que mejor pasan por una TDD son los que tratan la auditoría como una evaluación pagada e independiente de la salud de la ingeniería, separada del deal. Los hallazgos son útiles incluso cuando el deal no cierra. El informe te dice qué arreglar a continuación, con el dinero de otro.

FAQ

¿Qué significa technical due diligence?

Technical due diligence es una auditoría independiente del software, la infraestructura, la seguridad y las prácticas de ingeniería de una empresa, contratada por un inversor o comprador antes de comprometer capital. Es la contraparte técnica de la due diligence financiera.

¿Qué es technology due diligence?

Lo mismo que technical due diligence. Los dos términos son intercambiables en contextos de software. Fuera de software (construcción, real estate, energía), “technical due diligence” puede significar un proceso distinto, así que conviene revisar el contexto.

¿Cuáles son los cuatro componentes de la due diligence?

En la due diligence corporativa general, los cuatro componentes son financiero, operacional, legal y RH. La technical due diligence es una corriente aparte con sus propias cuatro áreas: código y arquitectura, infraestructura y operaciones, seguridad y compliance, y equipo y proceso.

¿Cómo me preparo para una technical due diligence siendo un founder no técnico?

Corre el playbook de cuatro semanas de arriba: confirma la propiedad de IP por escrito, construye el inventario de servicios de terceros, reduce el bus factor poniendo un segundo ingeniero junto al codebase, limpia los hallazgos automáticos (secrets, falta de observabilidad) y escribe los cuatro documentos cortos que los auditores buscan (README, runbook de deploy, nota de incidente, overview de seguridad). Si el deal es grande, trae un technical advisor para las entrevistas.

¿Cuánto cuesta una technical due diligence?

Quien paga es el comprador, no la empresa auditada. Engagements típicos van de 15.000 a 75.000 dólares dependiendo del alcance y la firma. Para el founder, el coste indirecto es el tiempo del equipo consumido en la ventana de la auditoría: en general dos a cuatro semanas de distracción significativa para ingeniería.

¿Cuánto dura una technical due diligence?

De una a cuatro semanas de trabajo activo para el equipo de auditoría. Desde la silla del founder, planifica seis semanas de distracción parcial: preparación, auditoría, respuesta al informe.

¿Se pueden rechazar partes de la auditoría?

Técnicamente sí, en la práctica no. Cualquier cosa rechazada se convierte en red flag en el informe. La jugada correcta es negociar el alcance al principio con el comprador (algunas firmas se pasan de alcance por defecto) y luego cooperar plenamente con lo que esté dentro del alcance.