Almost every website project that goes over budget was underspecified, not overpriced. The quote was accurate for what the developer imagined, and wrong for what the client imagined, and nobody found out until halfway through.
You can prevent most of that from your side, before you approach anyone. Here is what makes a brief that produces an accurate quote.
Say what the website has to achieve, not what it should have
The most useful sentence in any brief is a business one.
"We need a website with a blog and a gallery" describes features. "We get most of our enquiries by phone and we want people to be able to book online instead" describes an outcome — and that tells a developer far more, including which features you actually need and which you do not.
Lead with what has to change. The feature list follows from it.
Count your pages, roughly
There is a large difference between a site with eight pages and a site with eighty, and an even larger one between eighty pages that share one template and eighty that are all different.
You do not need a sitemap. You need an honest estimate: how many pages, and how many genuinely different kinds of page.
Say who is producing the content
This is the single most common cause of a stalled project.
Be explicit about whether you are supplying the text and images, or expecting them to be written and sourced. If you are supplying them, say honestly when they will be ready. "We'll get you the copy next week" is where a great many projects quietly stop for two months.
List anything it has to connect to
Accounting software, a booking system, a CRM, a payment gateway, a courier's tracking, an existing customer database, a stock system.
Integrations are where estimates go wrong most sharply, because the answer depends entirely on whether the other system has a usable API. That is a question that can be answered in an hour before quoting, and not at all afterwards.
Say what happens to the old site
If you have an existing website, say so, and say whether its content and its addresses are moving across.
Migrating content and preserving URLs is real work — and skipping it is how businesses lose their search visibility at launch. It belongs in the quote, not in a conversation three days before go-live.
Give a budget range
This is the part people resist, and it is the part that helps most.
A range is not an invitation to spend all of it. It tells whoever is quoting which version of the project to scope. The same brief can be built at very different scales, and without a range you will get a quote for the wrong one — then spend two more rounds correcting it.
If you genuinely do not know, say that too. It is a legitimate answer, and a reasonable developer will suggest a scope rather than guess at a number.
Say what "finished" means
Specify what has to be true on launch day. Content loaded? Staff trained? Redirects in place? Analytics connected? Old site switched off?
Agreeing this in advance is what prevents the long, awkward tail at the end of a project where nobody can say whether it is done.
What a good quote looks like coming back
A brief like that should produce a proposal that:
- restates what it understood, in its own words, so you can catch a misunderstanding early
- lists what is included, specifically enough to be checkable
- lists what is not included, which matters just as much
- says what it needs from you and by when
- gives a price for that scope, and says how changes to the scope will be handled
If a quote arrives as a single number with no scope attached, that is not a quote. It is a guess, and you will be the one paying for its error bars.
One more thing
Send the same brief to everyone you approach. It is the only way the numbers you get back mean anything — and if a developer asks you good questions after reading it, that is usually a better sign than one who simply agrees with everything.