El desarrollador se fue. La agencia dejó de responder. El cofundador técnico siguió su camino. Como quiera que hayas llegado aquí, ahora tienes un sistema que genera ingresos y que nadie entiende, y todas tus decisiones están bloqueadas por la misma pregunta: ¿cómo de mal está?

Eso no se responde leyendo código, y no deberías responderlo preguntando al siguiente proveedor, cuyo incentivo es recomendar una reconstrucción. Se responde con una auditoría estructurada que produce evidencias. Diez días laborables bastan.

Las cinco preguntas que debe responder la auditoría

1. ¿Podemos operarlo? ¿Podemos desplegar, restaurar y recuperar sin el autor original?
2. ¿Podemos cambiarlo con seguridad? ¿Existe algún mecanismo que nos avise si un cambio rompe algo?
3. ¿Está expuesto? ¿Hay credenciales, vulnerabilidades o vías de acceso que haya que cerrar esta semana?
4. ¿Es nuestro? ¿Está intacta la cadena de titularidad y son compatibles las licencias con nuestro negocio?
5. ¿Cuánto cuesta el próximo año? Mantenerlo, ampliarlo o sustituirlo.

Todo lo que sigue sirve a esas cinco respuestas. Nada más pertenece a las dos primeras semanas.

Días 1–2: toma el control de los accesos

Antes de analizar, asegura la custodia. Inventaria cada cuenta de la que depende el sistema —hosting, dominio, DNS, base de datos, pasarela de pago, email, APIs de terceros— y confirma que están a nombre de una dirección corporativa que controlas, no de una personal de alguien que ya no está.

Es el paso más urgente y el que más se salta. Un sistema al que no puedes acceder no es un problema técnico: es existencial. Si un dominio o una cuenta de pagos está a nombre de un colaborador que se fue, inicia la recuperación de inmediato, porque tarda más que todo lo demás de este plan.

Días 3–4: demuestra que puedes desplegar y restaurar

Haz que un ingeniero despliegue un cambio trivial y visible —una corrección de texto— por el proceso que exista, documentando cada paso. Después restaura una copia de seguridad en un entorno limpio y confirma que los datos están íntegros y actualizados.

Si algo de esto falla, has encontrado el hallazgo más importante de la auditoría, y todo lo demás es secundario hasta arreglarlo. Un sistema al que no puedes desplegar y que no puedes restaurar todavía no es un activo.

Días 5–6: cartografíalo

Produce un diagrama de componentes, flujos de datos y dependencias externas. Identifica dónde viven los datos personales y de pago. Lista cada tarea programada y proceso en segundo plano, porque ahí es donde se esconde la lógica de negocio no documentada.

Este mapa es el entregable de vida útil más larga. Todo lo que hagas en los próximos dos años lo consultará.

Días 7–8: evalúa el riesgo

• Escanea dependencias con vulnerabilidades conocidas y anota cuáles son explotables dada la exposición real del sistema.
• Revisa el historial del repositorio en busca de secretos y rota todo lo que aparezca.
• Revisa el modelo de control de acceso: ¿se aplica la autorización en la capa de datos o se comprueba en la interfaz?
• Contrasta las licencias de cada dependencia con la forma en que distribuyes el producto.
• Confirma que cada contribuyente pasado está cubierto por una cesión de PI válida.

Días 9–10: pon precio a las tres opciones

Termina con cifras, no con adjetivos. Tres opciones, cada una con coste y plazo: mantener tal cual, estabilizar y ampliar, o sustituir de forma incremental. Incluye qué significa cada opción para los próximos doce meses de tu hoja de ruta.

Según nuestra experiencia, la opción intermedia gana mucho más a menudo de lo que los fundadores esperan al empezar la auditoría. Los sistemas que parecen poco fiables suelen estar simplemente sin documentar y sin pruebas, y eso son semanas de trabajo, no meses.

Qué hacer con el resultado

Corrige de inmediato todo lo de la categoría "expuesto", sea cual sea la decisión estratégica. Después elige un camino con las evidencias delante, en lugar de con la ansiedad de no saber. Y elijas lo que elijas, añade primero las pruebas y la documentación: de lo contrario estás a punto de heredarte a ti mismo el mismo problema.

Un sistema que nadie entiende no es un problema de deuda técnica. Es un problema de continuidad del negocio vestido de técnico.

Lo hacemos a precio cerrado, con informe escrito y opciones presupuestadas. A la mayoría de fundadores ya les han dicho que reconstruir es el único camino; más de la mitad de las veces, no lo es.