Most clients ask for a fixed price. Almost none ask for a fixed scope. We've come to think the second is the one that matters — and here's the working document we use to land both at once, in the same hour.
A prospective client emailed us last week. They wanted a fixed price for a dashboard. We replied with a question — could they describe, in two sentences, what the dashboard would do on a Wednesday afternoon — and the conversation stalled. A week later they came back with a sharper answer, and a smaller project. That is the entire essay, but the rest of it is worth writing down.
The pattern is so common we've stopped being surprised by it. Most enquiries start with a budget envelope and a vague description: a CRM, a dashboard, an ops tool. The budget number is firm and the description is soft, and the conversation drifts toward "what can we get for £X". This is the wrong shape. The number that wants to be firm is the scope, not the price — and once the scope is firm, the price almost always lands within ten per cent of the original envelope anyway.
Two numbers, not one
A useful project has two numbers attached to it before any code is written: a list of things the software will do (the scope), and a money figure attached to that list (the price). Most agencies sell the second and bury the first in a statement of work nobody reads twice. We've tried to invert that.
The reason is selfish. If the scope is fuzzy, every change request looks like a feature request to us and a bug fix to the client. We end up either eating the cost (slow death) or arguing about it (faster death). If the scope is sharp, both sides know exactly when something is inside the deal and when it's an addition — and additions, agreed up front to cost extra, stop being arguments.
"Fixed price without fixed scope is a magic trick. It works for one project and never again with the same client."
— A friend who runs a larger agency, on a long walk
The discovery document
The artefact that makes this work is small — three pages, written collaboratively in the discovery workshop, delivered as a PDF the same week. It has four sections, and the order matters.
- The Wednesday paragraph. Two or three sentences describing what someone on the team does with the software on a Wednesday afternoon. Not the demo. Not the onboarding. The boring, in-the-middle-of-the-job use.
- The screens. A bulleted list, never longer than seven. "A login screen" doesn't count; "the daily ops dashboard with the four widgets in section 3" does.
- The integrations. Every external system the software reads from or writes to, with the rough rate and the failure mode if it's unavailable.
- The not-list. A list of things we are explicitly not building, agreed up front. This is the section clients try to skip and the section that saves the most arguments.
That's the whole document. It is signed by both parties, attached to the contract, and pinned at the top of the project channel for the duration of the build. When a question comes up in week three about whether something is in the deal, we don't look at the contract — we look at the three-pager.
A sample build budget
| Line item | Estimate | Actual | | --- | --- | --- | | Discovery + scope doc | £750 | £750 | | Build · core scope | £6,400 | £6,180 | | Approved change · invoice export | £700 | £700 | | Hosting, first 12 months | £240 | £240 | | Two weeks post-launch support | incl. | incl. | | Total | £8,090 | £7,870 |
A real build budget, with one change request, anonymised. The actual landed below the estimate because the integration was simpler than feared.
When the scope changes
It always does. The interesting question is what happens when it does. On a fuzzy project, a change is a negotiation about whether it was always implied. On a sharp project, a change is a five-line email: here's the new thing, here's how long it will take, here's what it costs, yes or no.
We say yes to most of them. The reason we can say yes — and say it quickly — is the not-list. The not-list is not there to keep work out; it's there to make changes easy. If the boundary is sharp, you can cross it on purpose.
In the wild
On the bakery project last quarter, the not-list explicitly excluded a mobile app. Three weeks in, the client realised the line staff needed a phone-friendly view. We added a responsive layer in two days for £600. It would have been a fortnight of argument under a hand-wave fixed-price arrangement.
What this costs us
It is not free. A sharp scope document takes the better part of a day to write properly, and the discovery workshop costs us the morning we'd otherwise have spent shipping. We charge £750 for the workshop — deliberately a small number, refunded if the project proceeds — because asking for nothing turns the workshop into a free-consultation farm.
The maths still works in our favour. A project that ships on time, on budget, and inside an agreed scope earns roughly twice what the same project earns when it doesn't, once support, scope creep, and relationship cost is folded in. We have the spreadsheet; it isn't subtle.
The other thing it costs
A small number of clients walk away at the discovery stage. Either they aren't ready to articulate the Wednesday paragraph (in which case the project would have been painful anyway), or they don't want to commit to a not-list (ditto), or the workshop reveals the work is too small to be worth our minimum. In each case, we've saved both sides money; in two of three cases, the client has come back six months later with a clearer brief and we've built the thing properly.
The template, with the names changed
We've put a redacted version of the scope document — taken from a real project, with the client and any commercially sensitive numbers swapped out — on the writing index. It's three pages of plain English and one checklist. Take it, change it, ignore the bits that don't apply.
If you want help writing one for your project, the discovery workshop is the thing. We do two a fortnight, mostly via Meet, mostly with a printed copy of the four-section template in front of us. It is, genuinely, the most enjoyable hour in any project.