Sometimes you do not have an ongoing technology problem. You have one urgent question. Is this codebase any good? Is this agency ripping me off? Will this architecture survive diligence next month? Hiring a fractional CTO on a monthly retainer to answer a single question is overkill, and paying nothing and guessing is worse. The right instrument is a one-time technical review, and founders rarely know what one should cost or what it should contain.
Let me set expectations on both, because a review is one of the highest-leverage small purchases an early-stage founder can make, and it is easy to overpay or underscope.
What a review actually is
A one-time technical review is a fixed-scope engagement that answers a specific question and produces a written verdict you can act on. It is not ongoing leadership and it is not a build. Someone senior looks at your code, your architecture, your team, or a specific decision, and hands you back a plain-language assessment of the state of things and what to do about it.
The value is compression. An experienced technical operator can learn more about the real health of a codebase in a focused session than a non-technical founder can learn in months of asking the team "is everything okay?" I have written before about the architecture smells I look for in a 20-minute review; the point of that piece is that a trained eye extracts signal fast. A good review turns "I have a vague bad feeling" into "here are the three things that are actually wrong, ranked, with what each one will cost to fix."
What it should cost
A one-time review is priced as a fixed fee for a defined scope, not as a retainer. The number depends on depth.
A focused review, one question, a targeted look at a codebase or an agency proposal or an architecture decision, typically runs from a few hundred dollars for a quick expert read up to a few thousand for a proper written assessment. As a reference point, some fractional operators price their time around $150 to $350 an hour, so a focused half-day-to-day review lands in the low four figures.
A deeper review, a full technical audit ahead of a fundraise or an acquisition, where someone works through the codebase, the infrastructure, the security posture, and the team, is closer in shape to formal technical due diligence and is priced accordingly, commonly a few thousand up into five figures depending on the size of the system. The range is wide because "review my one integration" and "audit my entire platform before a Series A" are genuinely different amounts of work.
The way to sanity-check any quote is scope divided by depth. A fixed fee against a clearly defined question and a written deliverable is a review. An open-ended hourly arrangement with no defined output is not a review, it is the start of a retainer wearing a review's clothes, and you should price it as such.
When a review is the right purchase
Buy a review, rather than an ongoing engagement, when the question is bounded and the timing is specific.
Before you sign an agency contract, a review of the proposed scope and price tells you whether the timeline is realistic and the number is fair. Before you close a fundraise, a review tells you what diligence will find so nothing is a surprise in the room. When you have inherited a codebase, from a co-founder who left, an agency you are firing, or an acquisition, a review tells you what you actually own. When something feels wrong but nobody can name it, a review turns the feeling into a list.
Do not buy a review when what you actually have is a continuing need for someone to own the technology. If the answer to "and then what" is "and then I will have the next question, and the one after that," you do not need a review, you need ongoing leadership, and paying for a string of one-off reviews is the expensive way to get there. The review is a diagnostic; the retainer is treatment.
What you should get for the money
Insist on a written deliverable. A review that ends in a verbal "yeah, it is mostly fine" is worth very little and cannot be shared with a board, a co-founder, or an investor. A real review gives you a plain-language assessment a non-technical founder can read, a ranked list of issues by severity, and a concrete recommendation for each: fix now, fix later, ignore, or walk away. If the reviewer cannot explain their findings in language you understand, they have failed the assignment regardless of how good the technical work was, because the entire point is to inform your decision.
This is exactly what a structured teardown is built to deliver: a fixed-scope, written technical read you can act on. If that is the shape of what you need, the teardown is where to start, and if you are not sure whether one question or an ongoing engagement fits your situation, book a call and I will tell you which one you actually need.
FAQ
How is a review different from a fractional CTO retainer?
A review is a fixed-scope, one-time diagnostic that answers a specific question and ends with a written verdict. A retainer is ongoing ownership of your technology with no fixed endpoint. Buy the review for a bounded question; buy the retainer when the questions keep coming.
Is a cheap review worth anything?
A quick expert read on a narrow question can be genuinely useful and cheap. The risk is scope: a low price attached to a vague, open-ended "look at everything" produces a shallow answer. Cheap is fine when the question is narrow; be suspicious of cheap attached to broad.
Can a review replace formal due diligence?
For your own decision-making, often yes. For an investor's or acquirer's formal process, no, they will run their own. But a review before their diligence is how you find the problems first and fix or frame them, instead of getting surprised in the room.
What deliverable should I insist on?
A written assessment in plain language, issues ranked by severity, and a clear recommendation for each. If you cannot hand the output to your board or co-founder and have them understand it, the review did not do its job.