What should a website brief contain?

A good one fits on a page. Eight points: what the site is for, who the customer is, page types, whether design exists, whether content exists, integrations, languages and the deadline.

Do I need a forty-page specification?

No. A long brief written by a non-specialist usually hurts: it locks in decisions that should be discussed and skips what actually drives cost.

What should I leave out?

Specific technologies without a reason, colours and fonts, words like "modern" or "like Apple", a list of features for later, and instructions on how to build it.

Why do developers quote a range instead of a price?

Because they cannot see the scope and are pricing in risk. Those eight points usually turn a range into a number.

What should I ask for in return?

A phased estimate, a schedule with dependencies, a list of exclusions, clarity on who owns the domain and code, and the cost of changes after launch.

Why Write a Brief at All

Not for formality, and not for legal cover. For the estimate to be a number rather than a range. A developer who cannot see the scope prices in the risk — and you pay for their uncertainty. You do not need forty pages. A long brief written by a non-specialist usually makes things worse: it locks in decisions that should have been discussed and skips the things that actually drive the cost.

Eight Points Are Enough

What the site is for. One sentence: leads, sales, credibility, recruitment. The structure follows from it
Who the customer is and how they search. "Café owners, googling on a phone" is enough to change half the decisions
Page types, not pages. Home, service, case, article, contact is five templates. Forty pages on six templates costs less than nine on nine
Whether a design exists. A ready Figma file removes a whole phase and 25-40% of the cost
Whether the content exists. Copy, photos, product data. This is the number one reason projects run late
Every integration as a list: payments, CRM, booking, analytics, newsletter, delivery
Languages. A second one is not a translation but a duplicated structure and QA on every template
The deadline and what drives it. A launch, a season, a trade show — the plan can be built around a fixed date if it is known up front

A developer does not need to know how the site should look. They need to know what it must do and for whom. The first is their job; the second is yours.

What Not to Write

Specific technologies, unless you have a reason. "Build it in React" without one narrows the field and sometimes doubles the price
Colours and fonts. Those are the output of design, not an input to it
Words like "modern", "premium", "like Apple". Replace them with one link to a site you like and one sentence about why
Forty features "for later". Anything not needed at launch makes launch later and dearer
Instructions on how to build it. Say what the result must be; how is what you are paying for

The Three Questions That Save the Most

Ask yourself these before you send anything. Each moves the estimate more than any design preference. Who changes the text on the site after launch — you, or a developer? Will there be users who log in and do things? And how many genuinely distinct page types are there, counted honestly?

What to Ask For Back

An estimate broken into phases, not a single total
A schedule with dependencies: "design by the 14th, provided copy arrives by the 7th"
A list of exclusions. A quote is defined as much by those as by its total
Who owns the domain, hosting and code after delivery
What happens to changes after launch, and what they cost

Conclusion

A good brief fits on one page. It answers why, for whom, what has to work and by when — and says nothing about how. If a developer still quotes you a two-fold range after reading one, the brief is not the problem: they either did not understand the job or are pricing in a risk they have not mentioned. Both are worth raising before you sign.