How to scope a web project so the price doesn't drift

Why a fixed price drifts

A quote is only as solid as the understanding behind it. When a project comes in over budget, it is rarely because the developer worked slowly. It is because two people pictured different things from the same short brief, and the gap between those pictures only surfaced once money and time were already committed.

The whole point of scoping is to close that gap on paper, while it is still cheap to change your mind.

Write down what “done” means

“A booking system” is not a scope. It is a heading. Under it sit dozens of real decisions: who can book, what happens when two people book the same slot, whether payment is taken up front, what the confirmation email says, who can cancel and refund, and what the owner sees when they log in.

A good scope answers those questions in plain language before the build starts. You do not need technical detail — you need to describe the behaviour you expect, screen by screen, so that “done” is something both sides can point at rather than argue about.

Separate must-have from nice-to-have

Almost every project carries features that feel essential in a first conversation and turn out to be optional once the budget is real. Sorting them early is one of the most useful things you can do.

• Must-have — the thing does not work without it. This is what the fixed price covers.
• Should-have — valuable, but the product still launches without it. A candidate for phase two.
• Nice-to-have — write it down so it is not forgotten, then park it.

Shipping the must-haves first gets you something real and earning sooner, and it means the money goes to what actually matters.

Agree what happens when something changes

Requirements change — that is normal, not a failure. What matters is having agreed in advance how a change is handled. A one-line change request, a quick note on the cost and time impact, and a yes or no before it is built. No surprises on either side.

This is the single clause that keeps a fixed price honest. Without it, either the client feels nickel-and-dimed or the developer quietly absorbs scope until the project stops being worth doing. With it, everyone can say yes to good ideas with their eyes open.

The questions a good developer will ask you

You can judge a developer by the questions they ask before quoting. Vague brief, confident fixed price, no questions — that is a warning sign, because the risk has not gone away, it has just been hidden inside the number. Expect to be asked:

• Who uses this, and what is the one thing they need to do?
• What already exists that this has to connect to — payments, email, an existing system?
• What does success look like three months after launch?
• What is the deadline, and what is driving it?
• What is the budget range — so the proposal can be built to fit it, rather than guessed at.

Answering these turns a heading into a scope, and a scope into a price that holds.