Every studio has a version of this story. A client comes in with a project, the studio sends back an estimate, work begins, and somewhere around week eight the estimate is revealed to be fiction. The budget doubles. The timeline slips. Relationships fray. Sometimes the project recovers; sometimes it does not.
We have been on both sides of this. It is not a pleasant place to be. And the root cause is almost always the same: estimates made before the scope was understood.
What a scope actually is
A scope is not a list of features. A list of features is what the client asks for. A scope is what the product actually needs to do — which is often a different, usually shorter, list.
The difference matters because features accumulate. They appear in the brief, in the meeting notes, in the product manager’s assumptions about what goes without saying. By the time an estimate is made, the feature list is typically 30–50% larger than the problem actually requires.
A proper scope asks harder questions: what is the simplest version of this product that proves the idea works? What can wait for version two? What does the user actually need to accomplish, as opposed to what has been written down?
Why scoping is uncomfortable
Scoping takes time. It requires the client to sit with ambiguity — to resist the temptation to add things — which most clients find genuinely difficult. It requires the studio to say “we do not know yet” when the client wants a number.
It also frequently reveals that the project the client wanted is not the project they should build. That conversation is uncomfortable. But it is far less uncomfortable at week one than at week twelve, when the budget is half spent and the product is still wrong.
There is a commercial pressure that works against this. Studios that scope before they estimate appear slower and more expensive to get started than studios that send a number by Friday. Clients in a hurry pick the studio that moves fast. Then the engagement goes wrong, and the hurry turns out to have cost more than the scope week would have.
How we do it
We spend the first week of every engagement on discovery. We run structured sessions with the client to understand the problem, the users, the constraints, and — critically — what success actually looks like in concrete terms.
At the end of that week, we produce a scope document. It contains:
- A clear statement of the problem being solved
- A prioritised feature set — what is in v1, what is explicitly out
- An architectural decision: what we will build on and why
- An honest timeline with a stated uncertainty range
- A list of assumptions we are making and open questions that remain
Only after the scope document is reviewed and agreed do we produce a fixed estimate. At that point we are estimating against a known, agreed target — not a moving one.
What this means for clients
The scope week is not passive. Clients who sign and step back will not get the best result from it. We need access to the people who make decisions, to end users if they are available, and to the assumptions embedded in the original brief — including the ones that were never written down.
What clients get in return is an estimate they can trust. Not a number calculated to win the project. A number that reflects what the work will actually cost, with the uncertainty stated explicitly rather than hidden in contingency.
That estimate still has a range — all honest estimates do. But the scope is agreed, the assumptions are named, and when something changes we all know what changed and why.
The projects that go wrong almost always go wrong in the same way: the scope was never really defined, so there was never a shared understanding of what done meant. Fixing that at the start is not expensive. Fixing it at the end is.