La due diligence técnica cambia el precio

La due diligence técnica no es un concurso de calidad del código. Un comprador quiere saber qué hechos técnicos cambian el flujo de caja futuro, amenazan la propiedad del activo, retrasan la integración o hacen que el negocio dependa de una persona que podría marcharse después del cierre. Las abstracciones limpias resultan agradables. La entrega predecible, los derechos demostrables y el riesgo operativo controlado afectan a la operación.

He visto a compradores discutir durante días sobre convenciones de nombres mientras un proceso nocturno de liquidación no tenía responsable, build repetible ni una prueba capaz de demostrar que el resultado de ayer coincidía con el de hoy. Eso es empezar por el extremo equivocado. Una revisión útil sigue las consecuencias empresariales por el código, la ruta de despliegue, las personas y los contratos, y luego explica qué debe hacer cada hallazgo con el precio o las condiciones.

El comprador pone precio a la incertidumbre, no al estilo

Un comprador usa la due diligence técnica para convertir incógnitas en un plan con costes. El código aporta pruebas, pero es solo una parte. El historial de repositorios, los sistemas de build, la telemetría de producción, los registros de incidentes, los manifiestos de dependencias, los diagramas de arquitectura, los controles de acceso y las entrevistas revelan si el software puede seguir generando ingresos bajo otro propietario.

La primera distinción que suele confundirse es defecto frente a riesgo de la operación. Una consulta lenta con arreglo claro, responsable y radio de impacto limitado es un defecto. Un motor de facturación sin documentar que solo entiende un contratista es riesgo para la operación, aunque lleve años sin incidentes. El primero crea un ticket de ingeniería. El segundo puede justificar una retención, una condición de cierre, un acuerdo de transición o una valoración inferior, porque tanto la probabilidad de fallo como el coste de recuperación son difíciles de acotar.

Los revisores deben conectar cada hallazgo material con un mecanismo económico. ¿Exige una solución inmediata? ¿Bloquea una combinación de productos prevista? ¿Podría interrumpir ingresos, incumplir un contrato con clientes o impedir que el comprador opere el activo? ¿Necesita retener a un empleado concreto o comprar una licencia comercial? Un hallazgo sin ese puente es una observación, no diligencia.

Las etiquetas de gravedad por sí solas ocultan esa lógica. Dos hallazgos marcados como «altos» pueden tener efectos distintos. Un endpoint administrativo público puede exigir medidas antes del cierre. Una base de datos al límite de capacidad puede justificar un proyecto financiado tras la compra. Una contribución de código disputada puede requerir una indemnización. Indique la consecuencia y el control disponible antes de elegir un color.

El comprador también necesita un nivel de confianza. Si los revisores no pueden ejecutar el sistema, acceder a datos parecidos a producción o entrevistar al operador, no deben marcar la zona como limpia en silencio. Deben registrar la falta de pruebas como un riesgo propio. La ausencia de pruebas suele cambiar más las condiciones que un defecto conocido, porque nadie puede valorar con honestidad el límite superior.

El acceso al repositorio debe demostrar qué se compra

El acceso debe establecer integridad, historial y procedencia antes de revisar la arquitectura. Un repositorio de aplicación pulido puede distraer de scripts de despliegue ausentes, generadores de informes, firmware, tareas de base de datos o un directorio aparte que se copia a mano en los servidores de producción. La transacción abarca un sistema operativo en sentido amplio, no el repositorio que el vendedor abrió primero.

Pida un inventario que asocie cada componente de producción con un repositorio, ruta de build, responsable del despliegue, runtime, almacén de datos y entorno. Contrástelo con cuentas de nube, planificadores, registros de paquetes, sistemas de archivos de servidores, tiendas móviles, registros DNS y facturas de proveedores. Si un ejecutable genera ingresos pero no tiene ubicación de código fuente, el comprador puede estar adquiriendo un binario que no sabe reproducir.

El historial importa porque una instantánea actual no muestra autoría ni concentración del desarrollo. Obtenga el historial completo de commits, etiquetas, ramas necesarias para versiones soportadas, submódulos, almacenamiento de archivos grandes y artefactos de build no reproducibles. Compruebe si una importación de última hora aplanó años de historial. Puede ser inocente, pero impide analizar bien a los contribuidores y dificulta probar las declaraciones de propiedad intelectual.

Una secuencia corta de triaje proporciona un primer mapa. Ejecútela en una copia aislada, revise cada orden antes y adapte las rutas al repositorio:

git rev-parse --is-shallow-repository
git shortlog -sne --all
git log --all --format='%aN <%aE>' | sort | uniq -c | sort -nr | head -20
git ls-files | sed 's|/.*||' | sort | uniq -c | sort -nr | head -30
find . -maxdepth 4 -type f \( -name 'package-lock.json' -o -name 'go.sum' -o -name 'Cargo.lock' -o -name 'pom.xml' -o -name '*.csproj' \) -print
find . -maxdepth 4 -type f \( -iname 'license*' -o -iname 'notice*' -o -iname 'copying*' \) -print

El resultado esperado no es aprobado o suspenso. Es un conjunto de pistas: si el historial es superficial, qué identidades dominan los commits, dónde se agrupa el código, qué ecosistemas de dependencias existen y dónde aparecen avisos de licencia. Después hay que agrupar alias y excluir bots. Nunca equipare número de commits con propiedad o capacidad; los cambios generados, importaciones, programación en pareja y rebases lo distorsionan.

Por último, reproduzca una versión soportada desde un commit documentado. Registre la cadena de herramientas, secretos necesarios, artefactos externos, duración del build y sumas de comprobación cuando se espere salida determinista. Un build que solo funciona en el portátil de un empleado no es reproducible porque ese portátil esté disponible durante la revisión.

El riesgo de persona clave aparece en decisiones y operaciones

Hay riesgo de persona clave cuando la ausencia de alguien puede detener un cambio importante, una recuperación o un proceso empresarial. La concentración de commits es una pista, no el diagnóstico. El riesgo se esconde en decisiones sin documentar, credenciales privadas, rituales manuales de producción, relaciones con proveedores, correcciones de datos y autoridad para aprobar una versión.

Empiece por rutas críticas: captura de pedidos, liquidación, facturación, cierre de mes, informes regulatorios, cumplimiento y acceso de clientes. Para cada una, pregunte quién sabe explicarla, cambiarla, desplegarla y recuperarla. Cuatro nombres son mejores que uno solo si pueden actuar de forma independiente. Un equipo que llama al antiguo fundador antes de tocar una regla de precios sigue teniendo un único responsable efectivo.

Pruebe el conocimiento con trabajo, no solo entrevistas. Pida a otro ingeniero que siga una transacción de producción, encuentre la regla aplicable, haga un cambio inocuo fuera de producción, ejecute las pruebas y describa la reversión. Pida al suplente de guardia que restaure una copia representativa y diagnostique una tarea programada fallida. El observador debe anotar dónde se necesita información no documentada o permiso de otra persona.

El caso incómodo es un fundador capaz que quiere marcharse. A veces los compradores aceptan una promesa vaga de disponibilidad porque sustituir su contexto parece descortés o caro. Esa promesa es débil. Defina entregables de transición: runbooks concretos, recorridos grabados, transferencia de credenciales, versiones desplegadas en pareja, un simulacro de incidente y aceptación de quienes operarán el sistema. Si la dependencia es material, vincule la entrega a una condición de cierre, contrato de consultoría o plan de retención.

No confunda tecnología antigua con riesgo de un solo experto. Un entorno COBOL bien gestionado, con varios operadores, comportamiento productivo registrado, builds automatizados y recuperación ensayada, puede ser más seguro que un servicio moderno escrito el año pasado por un contratista que ya se fue. La edad tecnológica afecta a contratación y coste del cambio. El conocimiento concentrado afecta a continuidad. A veces coinciden, pero pruebas y remedios difieren.

El precio se mueve cuando el comprador debe financiar personal duplicado, retener a alguien en condiciones excepcionales, aplazar la integración o aceptar una exposición a caídas que no puede asegurar. Si un plan práctico de transferencia cierra la brecha antes del cierre, conviértalo en condición. Si el vendedor no puede transferir el conocimiento porque nadie lo conserva, trate la solución como parte del caso de inversión, no como tarea documental.

La exposición a licencias empieza por la procedencia

La revisión de licencias debe responder si el vendedor tiene derecho a transferir y operar cada parte material del producto. Un escáner de dependencias ayuda, pero no demuestra cesiones de empleados, propiedad de contratistas, fragmentos copiados, componentes comprados, derechos sobre datos de entrenamiento ni condiciones del código recibido de socios. Son preguntas de procedencia.

Cree una lista de materiales de software a partir de manifiestos, archivos de bloqueo, directorios vendor, imágenes de contenedores, clientes generados, paquetes móviles y paquetes del sistema operativo distribuidos con el producto. Compárela con lo que llega a clientes o producción. La documentación del grafo de dependencias de GitHub dice que su análisis estático procesa manifiestos y archivos de bloqueo compatibles. Ese límite importa: un JavaScript antiguo pegado en vendor o un binario guardado en una carpeta de versión puede quedar fuera del grafo.

Use identificadores SPDX para normalizar hallazgos. La especificación SPDX permite expresiones con AND, OR y WITH, que conservan distinciones destruidas por una columna llamada «licencia». GPL-2.0-only OR MIT ofrece elegir; LGPL-2.1-only AND BSD-2-Clause dice que ambas se aplican al conjunto descrito. Quien reduzca las dos a una lista de nombres puede recomendar la solución equivocada.

El escaneo produce acusaciones que hay que resolver. Para cada resultado material, registre componente y versión, cómo entra en el producto, si está modificado, dónde se distribuye o aloja, licencia detectada y concluida, avisos u ofertas de código exigidos, responsable y pruebas. Los abogados interpretan el derecho. Ingeniería demuestra uso y sustitución. Ninguna disciplina termina sola.

Trate con igual cuidado la propiedad del código propio. Compare contribuidores con fechas de empleo, acuerdos de cesión de invenciones, contratos de proveedores, anexos de adquisiciones y código importado de proyectos previos. Mire especialmente commits desde correos personales, dominios externos, becarios, agencias y fundadores antes de constituir la empresa. Una garantía firmada en el contrato ayuda, pero no elimina la reclamación de un tercero.

El precio cambia cuando un componente no puede distribuirse legalmente con el modelo previsto, sustituirlo retrasaría el plan o la propiedad sigue siendo discutible. Las brechas menores suelen caber en un calendario de cierre, limpieza de avisos, indemnización específica o depósito. No declare fatal toda dependencia copyleft. Distribución, enlace, modificación y texto real determinan obligaciones; las etiquetas generales no sustituyen el análisis legal.

Una suite de pruebas solo es evidencia si puede fallar

El estado de las pruebas importa porque el comprador cambiará el sistema después del cierre. El número de archivos y los porcentajes de cobertura dicen poco sobre si detectan regresiones empresariales. Mil aserciones sobre acceso a datos no protegen un cálculo de liquidación si nadie codificó el resultado esperado.

Ejecute la suite desde un entorno limpio con el comando documentado. Anote tiempo de preparación, servicios externos, tratamiento de secretos, duración, reintentos por inestabilidad, pruebas omitidas y fallos en la rama predeterminada. Introduzca después un pequeño fallo controlado en una regla importante y confirme que la prueba relevante falla por el motivo esperado. Revierta el cambio de inmediato. Esta mutación suele informar más que la cobertura porque prueba la capacidad del test de objetar.

Separe cuatro formas de evidencia. Las pruebas unitarias protegen reglas locales. Las de integración demuestran que los componentes concuerdan en protocolos y persistencia. Las de extremo a extremo ejercitan rutas desplegadas, pero suelen cubrir pocas variantes. Las comparaciones o repeticiones de producción muestran si un sustituto conserva el comportamiento observado. Ninguna reemplaza a las demás. Una suite web verde no valida un cálculo anual, y mucha cobertura unitaria no demuestra que las migraciones funcionen.

Lea el historial de fallos de integración continua. Una rama principal roja que todos ignoran muestra un fallo de control, aunque cada error tenga explicación. También lo hace una suite que solo pasa tras reintentos. Pregunte cómo se aíslan pruebas inestables, quién puede saltar controles, si las ramas protegidas exigen resultados y cómo difieren los hotfixes del camino normal.

Los datos de prueba crean su propio riesgo. Determine si los fixtures contienen datos de clientes o empleados, cómo se enmascaran, quién accede y si las obligaciones de borrado alcanzan copias y respaldos. El comprador no quiere descubrir durante la integración que el entorno más rápido depende de un volcado de producción sin gestionar.

Traduzca el resultado a coste de cambio. Las pruebas débiles obligan a lanzar más despacio, comprobar más a mano, aceptar más incidentes o invertir pronto en pruebas de caracterización. Si la hoja de ruta asume integración rápida o reescritura, la falta de evidencia de comportamiento puede mover el precio porque no hay una forma barata de demostrar que el software cambiado sigue dando los mismos resultados.

La operabilidad revela la factura oculta de ingeniería

La operabilidad muestra cuánto trabajo consume el software tras desplegarlo. Los compradores deben revisar versiones, observabilidad, restauración, respuesta a incidentes, capacidad y reparación habitual de datos. Un producto puede parecer estable porque dos personas experimentadas evitan fallos visibles cada día. Ese trabajo pertenece al modelo de costes.

Observe un despliegue normal y, si el calendario permite, una reversión urgente. Identifique puertas manuales, cuentas compartidas, comandos sin documentar, servidores mutables y aprobaciones que solo existen en chat. Confirme que la versión desplegada se puede vincular con el código y que el equipo sabe qué migraciones se ejecutaron. Un documento que describe la ruta ideal y no la real es decoración.

Pida registros de incidentes y alertas de muestra, y siga un caso reciente desde detección hasta corrección. Las pruebas útiles incluyen marcas de tiempo, propiedad de alertas, logs, métricas, comunicación con clientes, seguimiento y prueba de que la corrección llegó a producción. La ausencia de incidentes registrados puede significar gran fiabilidad. También puede significar que no se registran. Telemetría y entrevistas distinguen los casos.

Las copias necesitan una prueba de restauración. Una captura de trabajos programados demuestra que se ejecutó una tarea, no que el negocio pueda recuperarse. Restaure datos representativos en un entorno aislado, compruebe integridad, mida el proceso e identifique credenciales o accesos de proveedor necesarios durante una caída real. Compare el resultado con promesas a clientes y objetivos internos sin inventar una precisión jamás medida.

Las correcciones manuales de datos son otro punto ciego. Busque en tickets, scripts, notebooks e historial de shell ajustes de saldos, pedidos, permisos o informes. Determine quién los aprueba, si se registran y si el defecto original permanece. Las correcciones frecuentes y seguras pueden ser operación normal. Las escrituras no revisadas en producción crean exposición financiera y de auditoría.

Este trabajo cambia el precio cuando el relato de márgenes omitía trabajo recurrente, hace falta capacidad antes de crecer, la recuperación no cumple compromisos o la integración elimina una dependencia asumida por el sistema. Cambia condiciones si el vendedor puede completar una restauración, transferir cuentas o arreglar un control peligroso antes del cierre.

La arquitectura importa cuando limita la tesis de compra

La revisión de arquitectura debe probar el uso previsto por el comprador, no premiar diagramas de moda. Un monolito puede ser una adquisición sensata si se despliega de forma predecible y sostiene el crecimiento. Un grupo de servicios puede ser un pasivo si la propiedad está difusa, las llamadas forman ciclos y cada versión exige cambios coordinados.

Asocie capacidades empresariales con módulos, almacenes, colas, interfaces externas y unidades de despliegue. Confronte ese mapa con la tesis. Si el comprador quiere combinar identidades, ¿el sistema separa inquilinos y reconcilia usuarios? Para expansión internacional, ¿dónde viven las suposiciones de moneda, impuestos, zona horaria y ubicación? Si los ahorros dependen de consolidar infraestructura, ¿qué servicios propietarios o fronteras de red lo impiden?

Busque restricciones con pruebas: runtimes sin soporte, avisos de fin de vida, tablas sin límites, llamadas síncronas en rutas de ingresos, bases compartidas, supuestos de entorno fijados en código y ventanas batch casi llenas. No convierta antigüedad en gravedad automáticamente. Un runtime viejo tras una interfaz estable puede tener sustitución acotada. Un framework nuevo con dependencias abandonadas puede ser más difícil.

Los datos suelen ser la parte dura. Revise propiedad del esquema, historial de migraciones, retención, identificadores, duplicados, auditoría y conciliaciones. Pregunte cómo se reparan fallos parciales y cómo conocen las correcciones los consumidores posteriores. Si dos productos usan la misma palabra para entidades distintas, una pasarela API no resuelve el conflicto semántico.

Estime el cambio por segmentos de comportamiento observable, no por líneas. Elija una ruta empresarial, liste entradas, salidas y dependencias y pida al equipo explicar cómo la movería o sustituiría. La respuesta revela si hay límites reales. También descubre trabajo oculto en procedimientos almacenados, clientes de escritorio, hojas y tareas que los diagramas omiten.

Una estimación de reescritura no es una deducción automática. Lo es cuando el retorno depende de la reescritura, el sistema bloquea otro cambio necesario o mantenerlo impone un coste omitido. Si no, un sistema anticuado pero controlado merece un presupuesto de modernización, no un descuento de pánico.

Los hallazgos de seguridad necesitan ruta y remedio

Un hallazgo de seguridad afecta a la transacción si crea una ruta plausible hacia daño material o revela un control que el comprador deberá aportar. La gravedad del escáner es un inicio. Exposición, privilegios, datos alcanzables, mitigaciones, requisitos de explotación y detección determinan el riesgo empresarial.

Siga la identidad desde el login del cliente hasta el acceso administrativo y credenciales de máquina. Revise ciclo de cuentas, roles privilegiados, uso de varios factores cuando se admita, responsables de cuentas de servicio, secretos y acceso de emergencia. Muestree cuentas reales en vez de aceptar la política. Extrabajadores con credenciales activas y contraseñas compartidas son hechos; una frase general sobre mala gestión no.

Para vulnerabilidades, demuestre si el componente está desplegado y accesible. Registre versión, ruta de llamada, control de entrada, frontera de privilegios, datos en riesgo, control compensatorio y camino de actualización o retirada. Un hallazgo en herramientas de prueba merece tratamiento distinto a la misma biblioteca en un servicio público. Ambos necesitan decisión, pero las pruebas fijan prioridad.

Revise cómo la empresa recibe, clasifica, corrige y comunica informes. Inspeccione parches recientes y el camino del aviso a producción. Si hubo un incidente, compare registros técnicos con avisos a clientes, declaraciones al seguro, correspondencia regulatoria y divulgaciones de la operación. La incoherencia puede importar más que el fallo inicial porque cuestiona las declaraciones de la dirección.

Los clientes regulados añaden requisitos, pero admitir un entorno regulado no equivale a tener certificación. Pida el control contractual exacto, límite del sistema, evidencia y responsable. No convierta una elección de alojamiento o un informe de penetración en una afirmación general de cumplimiento. El comprador hereda las promesas firmadas, no los adjetivos de ventas.

Una intrusión inmediata, incidentes no declarados o fallos sistémicos de acceso pueden bloquear el cierre. Las vulnerabilidades reparables suelen ir a un calendario con propietario y prueba. La distinción conserva credibilidad: si cada paquete antiguo amenaza la operación, nadie escuchará cuando uno de verdad deba hacerlo.

Los hallazgos mueven el precio por pocos mecanismos

Un problema técnico cambia la economía mediante coste de arreglo, beneficio retrasado, coste recurrente, ingresos perdidos o interrumpidos, pasivo contingente o mayor probabilidad de que falle la tesis. Los revisores deben evitar falsa precisión, pero mostrar mecanismo y supuestos.

Use un registro de decisión para cada hallazgo material. Esta es la forma mínima que espero:

Finding: Settlement rules have one effective owner
Evidence: Only one engineer can trace, change, deploy, and recover the nightly job
Business path: Customer settlement and finance reconciliation
Deal effect: Integration cannot safely begin on the planned date
Control before close: Backup owner completes a change and recovery exercise
Residual action: Add characterization tests around recorded settlement cases
Owner and evidence date: [named person] / [date]
Term response: Closing condition or funded retention agreement
Price response: Cost only if the control cannot be completed
Confidence: Medium, recovery was observed but a live release was not

El registro separa el hecho de la respuesta y evita contar dos veces. Si el modelo ya incluye modernización, no descuente el mismo trabajo salvo que la revisión amplíe alcance o riesgo. Si un plan de retención controla el riesgo de experto único, no valore además como seguro todo el escenario de caída. Muestre el riesgo residual tras el control.

Mecanismos distintos requieren herramientas distintas. Una solución conocida y acotada puede reducir precio o aumentar presupuesto. Un hecho corregible puede ser condición de cierre. Un riesgo concreto de propiedad o divulgación puede exigir declaración, indemnización, depósito o retención diseñados por abogados. La inversión futura incierta puede afectar a earn-outs o al caso de inversión, aunque un earn-out mal diseñado crea incentivos propios.

Ordene hallazgos por decisión, no por gravedad del escáner. El consejo necesita saber qué impide firmar, qué debe ocurrir antes del cierre, qué cambia valor, qué entra en el primer plan y qué acepta el comprador. El detalle técnico queda debajo, pero un catálogo de cien páginas no sustituye esas decisiones.

La calidad de la evidencia merece su propia conclusión

El informe debe decir qué observaron, recibieron y reprodujeron los revisores, y qué quedó inaccesible. La calidad de la evidencia controla la confianza en cada conclusión. Un diagrama del vendedor y un despliegue observado no merecen el mismo peso.

Use etiquetas sencillas: reproducido, observado, documentado, declarado y no disponible. Reproducido significa que el revisor ejecutó el proceso y obtuvo el resultado. Observado, que el equipo lo hizo ante él. Documentado, que un artefacto apoya la afirmación. Declarado, que alguien la hizo. No acusan de deshonestidad; muestran incertidumbre.

El muestreo también necesita límites. Si se revisan tres servicios de cuarenta, diga por qué se eligieron y qué riesgos quedan fuera. Elija rutas de ingresos, componentes privilegiados, cambios recientes y problemas conocidos antes que repositorios ordenados. El azar puede complementar el juicio, pero suele perder los sistemas capaces de dañar la operación.

Las restricciones de acceso son hallazgos si impiden una conclusión material. Una base de producción puede quedar fuera con razón, pero el vendedor suele poder dar esquemas, muestras enmascaradas, planes de consulta, tráfico grabado o una sesión observada. Si no hay sustituto, registre la pregunta y su efecto posible. No convierta «no probado» en «sin problemas».

La lectura final debe servir a ingeniería, finanzas, abogados y dirección de la operación. Cada grupo necesita los mismos hechos con resolución distinta. Mantenga una fuente única para evidencia y decisiones, evitando que un cambio tardío deje diapositivas, hojas y anexos contradictorios.

El primer plan operativo empieza antes de firmar

Una buena due diligence técnica deja al comprador un plan ejecutable de propiedad, aunque la operación no cierre. El resultado más útil es una lista breve de decisiones controladas: qué riesgo cambia condiciones, qué prueba falta, quién posee cada acción previa y qué trabajo entra en el plan financiado después.

Ordene el trabajo por dependencia y consecuencia. Asegure el acceso administrativo antes de cambiar despliegues. Capture comportamiento productivo antes de reemplazar reglas. Transfiera conocimiento de proveedores y operadores antes de que expiren preavisos. Ensaye restauración antes de consolidar infraestructura. Son controles concretos, no un backlog genérico.

El código heredado suele concentrar conocimientos escasos, pruebas débiles, procedencia mixta y comportamiento repartido por procesos batch, procedimientos, escritorio y hojas. CodeHero trata ese caso leyendo todo el código, reescribiendo la arquitectura en Go, Rust, TypeScript y Postgres cuando corresponde y comprobando paridad contra tráfico de producción registrado, con entrega en menos de 30 días. Esto cambia la opción de remedio, pero el comprador sigue necesitando propiedad limpia, evidencia fiable y autoridad para operar.

No termine con una puntuación media. Nombre la condición bajo la cual la operación aún funciona. Si el comprador puede dominar el despliegue, retener o transferir conocimiento crítico, resolver excepciones de licencia y medir paridad, el riesgo técnico tiene límites. Si no se cumplen esas condiciones, el precio debe cargar la incertidumbre en vez de dejar que integración la descubra después de firmar.