A number given before the scope is understood is a guess, and guesses get corrected in your direction.
A number given before the scope is understood is a guess, and guesses get corrected in your direction.
A brief describes what someone wants. A scope describes what has to be built. The gap between them is where budget overruns live.
We would rather spend a short paid phase establishing the scope than hand over a number that has to be revised the moment work starts.
The content that has to be carried, the integrations that must exist, the people who will maintain it, the constraints that cannot move, and the level of design ambition. Each of those moves the number.
A scope you could hand to another studio, a price with the assumptions written down, and a clear statement of what is not included. If your requirements change later, everyone can see exactly what changed.
A fixed price is honest when the scope is genuinely known. When it is not, a fixed price simply moves the risk onto whoever did the guessing, and that cost reappears later as change requests, padding, or corners quietly cut.
For exploratory work we would rather agree a budget envelope and review it at each stage. You keep control, we keep the ability to tell you the truth about what we are finding.
Every quote rests on assumptions: content will be supplied by a certain date, one round of revisions per stage, the third-party integration has a documented API that actually works.
Unwritten assumptions become arguments. Written ones become a conversation about trade-offs, which is a much better conversation to be having when something changes.
Not page count, which is what most briefs lead with. Integrations, unusual permissions, content migration, and the number of people who have to approve things move a quote far more than how many pages there are.
A twelve-page site with three integrations and four approvers costs more than a forty-page brochure site. Scoping by page count is the most common way to arrive at a number that cannot survive contact with the project.
Estimates are not usually wrong because the work was harder than it looked. They are wrong because something was missing from the picture: a legacy system that has to keep running, an approval step nobody mentioned, content that does not exist yet, an integration whose documentation turns out to be aspirational.
The second cause is optimism about the client's side. Every project plan assumes feedback within a few days and content by a date. When either slips, the cost of the project rises even though the amount of work has not changed, because a team held open is a team being paid.
So we scope the parts we cannot see, and we write down what we are assuming about you as explicitly as what we are assuming about the code.
A list of pages or screens with a complexity note against each, because eleven simple pages and eleven complex ones are not the same project. A list of integrations, each marked as documented, undocumented, or unknown. A statement of who supplies content, images and legal copy, and by when.
A revisions policy in numbers rather than in the word reasonable. Two rounds at design, one at build, more available at a stated rate. This protects both sides: it stops scope drifting for free, and it stops us treating a fair request as an extra.
An explicit list of what is out of scope. This paragraph prevents more arguments than everything above it combined.
We get estimates wrong. When we do and the cause is ours — we misjudged the work, we missed something we should have seen — we absorb it, because that is what a fixed price means and a quote nobody can rely on is worth nothing.
When the cause is a genuine change in what was asked for, we say so at the time rather than at the end. A variation raised in week three is a conversation. The same variation raised in the final invoice is a dispute, and it is the same money either way.
The aim is not to be right every time. It is that you are never surprised.