Due diligence técnica: qué debe revisar el comprador

La due diligence técnica es una revisión estructurada del código, la infraestructura, el equipo y la seguridad de un producto de software, que se hace antes de comprar una empresa, invertir en ella o fusionarse con ella. El objetivo es averiguar si lo que te dijeron sobre la tecnología coincide con lo que realmente corre en producción, y cuánto costará mantenerla funcionando y creciendo.

Como regla práctica (estimación mía, no una cifra de mercado), una due diligence técnica enfocada toma de unos días a algunas semanas y termina con un informe breve que ordena los riesgos según su efecto en el precio, las condiciones y el roadmap. Así es como yo la haría, a partir de siete años construyendo productos de punta a punta y liderando la migración en vivo de una plataforma en producción a un nuevo stack.

¿Qué es la due diligence técnica y quién la necesita?

Es la parte técnica de la revisión de una empresa antes de una transacción. Aplica a adquisiciones, rondas de inversión, fusiones y compras de un producto a una agencia o a un desarrollador independiente. También sirve a fundadores que heredan una base de código cuando un desarrollador se va, porque la pregunta es la misma: ¿qué es exactamente nuestro y qué hará falta para mantenerlo vivo?

Quienes suelen necesitarla:

• Compradores que adquieren una empresa de software o un producto.
• Inversionistas cuyo cheque depende sobre todo del valor del software.
• Fundadores y CTOs que reciben un sistema de una agencia o de un ingeniero que se fue.
• Empresas a punto de unir dos equipos de ingeniería o dos plataformas.

Es más amplia y menos profunda que una auditoría de código. Una auditoría lee el código a fondo. La due diligence cubre código, entrega, infraestructura, seguridad, personas y contratos, y reparte el tiempo en proporción al riesgo. Si encuentra un área preocupante, después puede venir una auditoría más profunda de esa área.

¿Cómo es un proceso de due diligence técnica?

Ponle un plazo fijo. La secuencia importa más que la duración, y replica los primeros 30 días al heredar un sistema.

1. Accesos. Pide acceso de lectura a los repositorios, la consola de la nube, el CI/CD, el monitoreo de errores, la analítica, el registrador del dominio, las cuentas de las tiendas de apps y los servicios de terceros. Verifica quién es titular de cada cuenta: la empresa, una agencia o una persona. Si el vendedor no puede darte acceso en un plazo razonable, eso ya es un hallazgo.
2. Build. En una máquina limpia, sigue solo la documentación escrita para compilar y ejecutar el producto. Corre las pruebas. Despliega en un entorno de staging si existe. Anota cuánto tardaste y qué faltaba en las instrucciones.
3. Flujos de dinero. Rastrea cada flujo que genera o mueve dinero: registro, checkout, suscripciones, facturación, pagos a terceros. Lee el código, las pruebas y el manejo de errores de cada uno. Trabajar en el equipo de carrito y checkout de Total Wine & More me enseñó cuánto se esconde en los casos límite de estos flujos, así que aquí es donde paso las horas más cuidadosas.
4. Riesgos. Solo entonces amplía el alcance: seguridad, dependencias, datos, infraestructura, personas y licencias.

Termina anotando lo que no pudiste verificar. Las afirmaciones no verificadas también son riesgos, y el informe debe decirlo.

¿Qué preguntas revelan el estado real de la base de código?

Los vendedores suelen describir el sistema como fue diseñado, no como se comporta. Estas preguntas obligan a dar respuestas concretas, y la tabla muestra lo que busco escuchar.

Tres hábitos en los que confío:

• Lee el historial de git. ¿Quién hizo commits en el último año, con qué frecuencia, y los autores de las partes críticas siguen cerca?
• Pide el último incidente en producción. Un equipo que puede explicarte qué se rompió, cómo lo detectó y qué cambió después suele estar en mejor forma que uno que dice que nunca se rompió nada.
• Lee un flujo de dinero de punta a punta. Una hora en el código de checkout o de cobro te dice más que una presentación.

¿Cómo evalúas los riesgos de equipo, infraestructura y seguridad?

Equipo

Liderar a más de 15 personas en web, mobile y e-commerce me enseñó que el conocimiento en una sola cabeza es el activo que se deteriora más rápido. Pregunta quién entiende cada área crítica, quién se va y qué está documentado. Revisa cómo se revisa el código y cómo se deciden los releases. Si el producto lo construyó una agencia o contratistas, confirma quién sigue bajo contrato después del cierre. Si la empresa es realmente dueña del código que escribieron es una cuestión legal, así que pide a un abogado que revise los contratos. Sobre las prácticas de release, pregunta si usan un despliegue canario para exponer los cambios primero a pocos usuarios.

Infraestructura

Estos son los puntos que reviso primero:

• Si la cuenta de la nube pertenece a la empresa, y no a un exdesarrollador o a una agencia.
• Si la infraestructura está descrita en código o vive en la memoria de alguien y en una consola. Si los datos pasan de una base de datos a otra durante una migración, pregunta si change data capture mantiene ambas sincronizadas.
• Si existen backups y, más importante, si alguien ha restaurado uno. Pide una prueba de restauración.
• Si existen monitoreo y alertas, y a quién se le avisa.
• Puntos únicos de falla, y la tendencia de la factura de la nube comparada con el uso.

Seguridad

No necesitas una prueba de penetración completa para encontrar lo básico. Busca secretos subidos en el historial del repositorio. Revisa cómo funcionan la autenticación y la autorización, quién tiene acceso de administrador y si se dio de baja a exempleados y contratistas. Ejecuta un escaneo de vulnerabilidades de dependencias y lee los resultados con contexto. Revisa cómo se almacenan y se registran los datos personales. Si el backend depende de una base de datos alojada con reglas de acceso, como row level security, comprueba que esas reglas estén realmente activadas y probadas. Las obligaciones de cumplimiento, como las leyes de privacidad o los cuestionarios de seguridad de clientes, corresponden a un abogado o a un especialista en cumplimiento.

¿Qué debe incluir un informe de due diligence técnica?

Mantenlo lo bastante breve como para que alguien que no es ingeniero pueda actuar a partir de él. Una estructura útil:

• Resumen y veredicto. Dos párrafos: ¿el producto es lo que el vendedor afirma, y cuáles son los principales riesgos?
• Alcance. Qué se revisó, cómo, y qué no se pudo verificar.
• Panorama del sistema. Stack, hosting, servicios de terceros y un esquema simple de la arquitectura.
• Hallazgos ordenados por gravedad. Cada uno con evidencia (un archivo, una captura de pantalla, un paso que falló), no con opiniones.
• Estimaciones de esfuerzo. Rangos, claramente señalados como estimaciones, para corregir los hallazgos principales.
• Dependencias de personas. Quién tiene el conocimiento crítico y qué pasa si se va.
• Primeros 30 y 90 días. Qué hacer justo después del cierre.
• Preguntas abiertas para el vendedor. Puntos por resolver antes de firmar.

Evita las calificaciones sobre diez sin explicación. Quien decide necesita saber qué significa cada hallazgo, cuánto cuesta y qué hacer después.

¿Qué hallazgos deberían cambiar el acuerdo o el roadmap?

Hallazgos que cambian el acuerdo

• El vendedor no controla los activos: el código, el dominio, la cuenta de la nube o la ficha en la tienda de apps están en manos de un tercero.
• Los flujos de ingresos no se pueden verificar, o los flujos de dinero están rotos de maneras que los usuarios todavía no han notado.
• Un incidente de seguridad no revelado o datos de clientes expuestos.
• Posibles problemas de licencias en el código o en las dependencias, que debe confirmar un abogado.
• Todo el sistema depende de una persona que no se va a quedar.

Según la gravedad, las respuestas pueden ir desde un precio más bajo hasta condiciones que deben cumplirse antes del cierre, retenciones de pago o retirarse del acuerdo. Cómo estructurar esas condiciones es una pregunta para tu abogado, no para un ingeniero.

Hallazgos que cambian el roadmap

La mayoría de los hallazgos no tumban un acuerdo. Reorganizan el primer trimestre: frameworks sin soporte, falta de pruebas en los flujos críticos, deploys manuales, backups sin prueba de restauración. Arregla primero la red de seguridad y después cambia el producto.

Si los hallazgos apuntan a reemplazar el stack, resiste el instinto de planear una reescritura. Una reescritura suele costar más y tardar más que una migración incremental, porque el sistema viejo tiene que seguir funcionando en paralelo. Prefiero poner un punto de desvío delante de todo antes de escribir código nuevo, y luego mover el sistema pieza por pieza mientras sigue en línea. Así encaré la migración completa de una plataforma que postula a vacantes de empleo automáticamente, mientras sus usuarios la seguían usando todos los días.

¿Quieres una segunda opinión sobre tu caso?

Si estás a punto de comprar, invertir en o heredar un producto, escribe a me@filipeeduardo.dev con el stack y lo que está en juego, y te diré qué revisaría primero.