The cheapest hour is the audit

A technical audit is two days of somebody senior reading your system and writing down what they found. It is the cheapest hour in most projects, and it is almost always scheduled in the wrong place: after the proposal, as a formality, or never.

Here is what it actually finds, drawn from the audits we have done.

The thing that is not yours

More often than anyone expects, the system being asked to change contains a service nobody on the current team owns. A queue nobody remembers setting up. An S3 bucket from a migration four years ago. An API key in an environment variable with no record of what it authenticates against.

This is not a failure of the previous vendor. It is what happens to every system that is worked on for three years without anyone writing it down. But it is very expensive to discover halfway through a rebuild, because it changes the shape of the work.

The load-bearing assumption

Every codebase has one thing that is load-bearing in a way nobody documented, usually because it looked like a workaround at the time. A nightly job that reconciles two databases. A retry loop that is quietly masking a third-party API's rate limit. A single-table lookup that is fine until you have ten million rows.

A rebuild deletes all of this. Some of it was load-bearing for a reason. If nobody writes down what it was doing, you find out in production.

What is actually slow

Teams have opinions about why their site is slow, and those opinions are usually wrong. Two days of profiling finds the real answer, which is frequently something nobody suspected: an N+1 in an endpoint that is not obviously a database endpoint, a third-party script nobody owns, an image pipeline that has been generating six sizes since 2019 and using none of them.

The number is usually a small, specific, fixable thing. It is rarely "the framework".

What is actually risky

A lot of rebuild proposals are scoped from the outside, on the basis of what the API looks like, without anyone reading what runs underneath it. So the proposal is confident and the estimate is wrong.

An audit produces the input data the estimate needs. A confident proposal without it is a guess with a total on it.

What we hand you

Not a findings document that goes in a drawer. Three things:

1. A recommendation, including "do not rebuild". A significant fraction of the audits we do end with the conclusion that the client should fix two things and spend the rest of the budget elsewhere. We write that down and we mean it, because the alternative is selling the rebuild we were always going to sell.
2. A scoped proposal with what is explicitly not included, and the assumptions we are making, written where you can argue with them.
3. A prototype of the riskiest part. Not a spec for it — a running thing, so the hardest assumption in the project is tested before you commit the budget to it.

Why it comes first

Because the alternative is paying for a build whose estimate was made before anybody knew what they were building.

The pattern is always the same. A quote comes in at a number. Three months in, something surfaces that changes the scope. The change is agreed at a higher price than the original quote, and by then both sides have lost the leverage they had in week one.

Two days up front is expensive insurance against a conversation you cannot win later.

When to skip it

Honestly: if the work is small, well understood and you already know the answer, skip it. We do not need an audit for a bug fix, and charging for one would be a small way of being annoying.

It is worth it when the work touches something you did not build, someone else built, or nobody is still around who built it. That is most rebuilds.