Only the ability to read the code repositories and the billing data. We don’t need production data.

That is your decision. It goes faster if some of their time is available to confirm what the code can’t tell us.

Technical due diligence · Assessment

What’s in the codebase you’re about to buy or fund

Before you buy or fund a product, an independent written assessment tells you what its system costs to run, what it would cost to fix and which parts are sound.

Request this review See the proof

FormatWritten assessment

TimelineDate agreed up front

PricingFixed-price assessment · hourly work

Proof2 case studies

The assessment in 4 parts

01 · Signs you need it

If two of these apply, this is a good fit.

The product looks good in the demo, and nobody on your side has read the code
The cloud bill is one number that nobody can break down
The team says a rewrite is needed, or that none is, and you can’t check either claim
Only one or two people know what the system does, and they may not stay

02 · What you get

What the document contains:

What the system costs to run, broken down by billing meter, and how much of that comes from sizing, from faults and from the architecture.
Where the risks are: data access, secrets, authentication and anything else that would fail a security review.
A part-by-part view of what can stay and what would have to be rewritten, with the reasoning written out.
What we did not check, written down, so the document isn’t read as more than it is.

03 · How we decide

STEP 01The bill comes before the code.It shows quickly what the system really does. On one national identity system the bill was about eight times what the workload needed, and nothing had raised an error.

STEP 02Causes come first in the document.Typecheck, lint and a green build say little about whether the system does what its authors think it does. One cause can sit behind the next hundred findings, so we name it.

STEP 03We separate what can change from what can’t.Saved customer reports, installed apps and third-party systems often hold interfaces in place. Those limits, more than anyone’s preferences, decide what a new owner can change.

STEP 04We look for failures that raise no alarm.The costly ones look like normal operation: an endless loop, uploads routed through the backend, a code comment that has stopped being true.

Explained in:Technical due diligence: read the bill before the code From $24,000 to $2,000 a month on AWS: the three causes I found Three kinds of design system bug that TypeScript and ESLint miss

04 · If we find nothing

A sound codebase still gets the full document: why it is sound, its running costs broken down and the list of what we did not check. That is worth having in writing before you sign.

Proof