About once a month the same request lands in our inbox: 'Send us a ballpark price — we'll show you the code once we've agreed.' We understand why companies do it: they're ringing three agencies and want comparable numbers. We used to comply. These days we answer that we're happy to send a number — after we've seen the code. This note is about why we insist on that, even at the cost of occasionally losing the job.
We're writing this from the consulting side of our work — taking over existing systems, where a new client arrives with an app somebody else built. We've already written about what our paid two-week diagnostic looks like. This is the step before it: why even an ordinary proposal doesn't get written without a look inside.
A blind estimate is a guess with a signature
In 2021 we priced an extension to a booking system. The brief sounded simple: add a second branch and new price tiers. From the description, we estimated fifteen days. We saw the code for the first time after signing — and found a database without a single migration (the schema had been edited by hand on production for years), zero tests, and branch configuration hard-wired in forty places. Actual time: nearly triple. We swallowed the difference ourselves, but that helped nobody — the project dragged, and the client still waited longer than anyone had promised.
We could have blamed the brief. The truth is the mistake was ours: we signed a number we had no way of knowing. A feature description tells you what a system does. It tells you nothing about what state it's in — and it's the state that sets the price, not the features.
The half-day of reading that now precedes every number
Instead, before any proposal we ask for access to the code — read-only is fine — and spend roughly four hours in it. We don't read everything. We look at six specific things:
- Git history — who commits, how often, and when the last one landed. A repo whose last commit was made a year ago by someone who no longer works there is a different project from living code.
- Dependencies — the dates in the lockfile. A framework three major versions behind isn't a detail; it's a separate line in the budget.
- Migrations — whether schema changes live in code or the database was edited by hand. This is the single most reliable signal of overall discipline.
- Tests and CI — not coverage as a number, but whether any way exists at all to find out we broke something.
- Deployment — how code reaches production and how many people can do it. 'Peter deploys it over FTP' is an answer that changes the proposal.
- The worst endpoint — we open the gnarliest piece of business logic and read it whole. Ten minutes in the worst file says more than an hour in a pretty README.
What it does to the number
A proposal written blind has a real spread of plus-or-minus a hundred percent — it just doesn't say so on the page. After half a day in the code we can get to a spread we're not ashamed of, and more importantly we can say exactly what's pushing the price up: missing migrations, a manual deploy, dependencies past end-of-life. For the first time the client sees their system through an outsider's eyes — and sometimes that list is worth more than the proposal itself.
And sometimes the outcome is that we don't bid. Roughly one time in ten, after reading the code, we say the takeover doesn't make sense — that it's cheaper to let the system live out its days while a new one is built alongside it, or that we're simply not the right fit. That's a result too. Cheaper for both sides than a year of shared misery.
A proposal written without looking at the code isn't an estimate. It's a guess with a binding signature — and the risk of that guess is always carried by either the client or us.
When you can't just send the code
The most common objection is confidentiality, and it's legitimate. The solution is also routine: we sign an NDA (we keep a standard mutual one ready), get read-only repository access, or walk through the code together on a shared screen without anything leaving the company. In all these years it has never taken more than two days to sort out. The only genuine red flag is a different one: when nobody at the company can grant access to the code at all. That isn't an obstacle to the inspection — that's the first finding.
If you're taking over a system from another vendor, or just want a second opinion on the state of yours, get in touch. The half-day read is a free part of every proposal we send — and when it needs to go deeper, that's exactly what our two-week diagnostic is for.
