[Draft note for Manuel]: this is a narrower, decision-focused cut of "Architecture design & review" — confirm you're fine offering it as its own line item (common ask before a funding round, acquisition, or CTO transition) rather than folding it entirely into the architecture service.

Sometimes you don't need a full architecture engagement — you need a fast, honest answer to a specific question: is this codebase in good enough shape to build on, invest in, or take over? That's a different deliverable than an ongoing architecture review, and it runs on a different clock — usually days, not weeks, because a real decision is waiting on it.

I review a codebase or system from the outside and produce a report scoped to the decision at hand: real technical debt versus debt that can wait, security and scalability risks, how much of what exists depends on institutional knowledge that would leave with the team, and what it would actually take to keep building on it. Common moments this gets used:

Before an investment round or acquisition, when someone needs to know what they're really buying.
Before a new team or a new CTO takes over a system they didn't build.
Before committing budget to "rebuild vs. keep extending" — a decision that's expensive to get wrong either way.

The output is a written report with concrete findings, not a verbal opinion — something you can actually hand to the people making the decision.

Need an outside, structured read on a system before a decision depends on it? Let's talk.