A veces no hace falta un acompañamiento de arquitectura completo. Hace falta una respuesta rápida y honesta a una pregunta puntual: ¿este código está en condiciones de construirse encima, invertir en él, o tomarlo a cargo?

Es un entregable distinto a una revisión de arquitectura continua, y corre en otro reloj: normalmente días, no semanas, porque hay una decisión real esperando esa respuesta.

Revisamos el código desde afuera y entregamos un informe acotado a esa decisión: deuda técnica real frente a la que puede esperar, riesgos de seguridad y escalabilidad, cuánto de lo que existe vive solo en la cabeza del equipo actual, y qué haría falta de verdad para seguir construyendo encima.

Momentos comunes donde se usa:

Antes de una ronda de inversión o una adquisición, cuando alguien necesita saber qué está comprando de verdad.
Antes de que un equipo o un CTO nuevo tome a cargo un sistema que no construyó.
Antes de comprometer presupuesto a "reconstruir o seguir extendiendo", una decisión cara de equivocar en los dos sentidos.

El entregable es un informe escrito con hallazgos concretos, no una opinión verbal. Algo que se le puede pasar a quien toma la decisión.

Y si al leer el código resulta que el sistema está mejor de lo que temías, te lo vamos a decir igual. Lo que no hacemos es trabajar sin acceso al código ni a las personas que lo escribieron: sin las dos cosas, el informe sería una opinión con forma de informe.

¿Necesitas una lectura externa antes de que una decisión dependa de eso? Conversemos.