Skip to content
Web Development 6 min read Sajid Aslam

How to Write a Website Brief That Gets Accurate Quotes

Three quotes for 'a website' can differ by ten times. A two-page brief fixes most of that, and you do not need to be technical to write it.

Template layout for a website project brief

Short answer

A good website brief explains what the business does, what the site must achieve, who it is for, which pages and features it needs, what content exists and who will write the rest, what you already have, your budget range and deadline. Two pages is enough. Sending the same brief to every supplier is what makes their quotes comparable.

A website brief is a short document describing what your business needs from a website, written so that several developers can quote for the same thing. Writing one is the most effective way to get accurate quotes, because most of the difference between a £600 quote and a £6,000 quote comes from each supplier imagining a different project. You do not need to be technical. You need to be specific about the business.

Why briefs matter more than people expect

Without a brief, a developer fills the gaps with assumptions. One assumes you want a template with your logo. Another assumes custom design, copywriting and a booking system. Both quote honestly, and you end up comparing two different products as if they were the same.

A brief also exposes decisions you have not made yet. If you cannot write down what the site is for, no developer can build the right thing.

The ten sections of a good website brief

1. About the business

Two or three sentences: what you do, where, for whom, and how you win work today. Include anything that makes you different from competitors.

2. The goal of the website

The single most important section. What should a visitor do, and how will you measure it? For example: generate enquiries for commercial cleaning contracts in Kent; take bookings for physiotherapy appointments; sell gift vouchers online.

If there are secondary goals, list them in order of importance.

3. Who the site is for

Your main customer types, what they need to know before they contact you, and the questions they ask most often. This shapes content and structure more than any design preference.

4. Pages

A list of the pages you think you need. Do not worry about getting it perfect; a developer will refine it. Be specific about services: list each one, because each usually needs its own page. What pages does a business website need helps you build the list.

5. Features beyond content

Anything the site must do rather than just display:

  • Contact or quote forms, and where enquiries should go
  • Online booking or appointment scheduling
  • Payments, deposits or a full online shop
  • Customer logins or member areas
  • Integrations with a CRM, email marketing, accounting or stock system
  • Multiple languages
  • Search, filters, or a resources library

Each of these changes the price, so this section does more to make quotes accurate than any other.

6. Content

Who will write the copy? Who will supply photos? Do you have existing content that can be reused? Do you need copywriting or photography quoted separately?

Be honest here. Content is the most common cause of delays and the most common hidden cost.

7. What exists already

Current website address, if there is one. Where the domain is registered and who controls it. Current hosting. Brand guidelines, logo files, fonts and colours. Any existing systems the site must work with.

If there is an existing site, mention whether it gets meaningful search traffic. Protecting that during a rebuild is a separate task that should be quoted.

8. Sites you like, and why

Two or three examples, each with a sentence on what you like specifically: the layout of the service pages, the tone, the way the pricing is shown. "I like it" gives a developer nothing; "I like how each service page shows prices and a short FAQ" gives them a lot.

9. Budget and timeline

A budget range and a target launch date, with the reason for any hard deadline. A launch tied to an event is planned differently from a preference.

10. Who decides

Who will give feedback and who signs off. If several people must approve, say so; it affects the timeline.

A website brief template

Copy this, fill it in, and keep it to two pages:

SectionYour answer
Business summaryWhat you do, where, for whom
Primary goalOne sentence, plus how you will measure it
Secondary goalsIn order of importance
Main customer typesWho they are, what they need to know
PagesList, with each service named
FeaturesForms, booking, payments, integrations, logins
ContentWho writes copy, who supplies images
Existing assetsDomain, hosting, brand, current site, systems
ExamplesTwo or three sites, and what you like about each
Budget rangeA range, excluding or including VAT
TimelineTarget date, and why
Decision-makerName and role

Details that change the price most

When I read a brief, these are the lines that move the estimate furthest:

  1. Number of distinct page layouts, not total pages
  2. Functionality beyond content, especially bookings, payments and integrations
  3. Who produces the content
  4. Migration from an existing site with search traffic to protect
  5. eCommerce, and how many products with how many variations
  6. Deadline pressure, which may need more people or longer days

How much does a website cost in the UK explains why each of these drives cost.

What not to put in a brief

  • A technology choice without a reason. Saying you want React or a particular plugin limits the answers you get. If there is a reason, explain it.
  • A full design. Examples and preferences are useful; a finished mock-up removes the value of hiring a designer.
  • Every possible future feature. Separate must-haves from nice-to-haves, or every quote will include everything.
  • Vague adjectives. Modern, clean and professional describe almost every website. Point at examples instead.

A short worked example

A hypothetical brief summary for a physiotherapy clinic:

Two-clinic physiotherapy practice in Kent. Goal: online bookings for initial assessments, measured as completed bookings. Customers are mainly people with sports injuries and back pain who want to know cost, availability and whether we treat their problem. Pages: home, six treatment pages, two clinic location pages, team, prices, about, contact, FAQs. Must integrate with our existing booking system. We will write the copy; we need photography quoted. Current site gets some search traffic, so redirects are needed. Budget £2,500 to £4,000. Launch before our third clinic opens in March.

That paragraph alone is enough for three developers to quote for the same project.

What a developer should send back

A good response to a brief is more than a number. Expect:

  • Questions. If nobody asks anything, they have filled the gaps with assumptions. The questions often reveal who understood the brief.
  • A scope in their own words. Pages, templates, features, what is excluded. Compare this against your brief line by line.
  • A price, with what is optional separated out. Photography, copywriting and migration are often quoted as extras.
  • A timeline with the points where they need something from you.
  • Running costs: hosting, licences and maintenance, so you can see the cost of ownership rather than the build alone.

If a reply ignores half your brief, that is useful information too. The way a supplier handles a brief is a preview of how they will handle the project.

Sending the brief

Send the same brief to every supplier, and ask each the same follow-up questions: what is included, what is excluded, who owns what at the end, and what it will cost per year to run. Freelance web developer vs agency helps decide who to send it to, and the business website development guide puts the brief in the context of the whole project.

If you would like a quote from me, the website development service page explains each package, and a brief sent through the contact page gets a written response, including the questions I would need answering.

Related services

Related reading

FAQ

Questions about this

If yours isn't here, send it over — I reply within one working day.

Yes, as a range. Without it, developers have to guess what scale of solution you want, and quotes vary wildly as a result. A range lets them tell you what is realistic for that money and what would need to wait. If someone simply quotes the top of your range, you have learned something about them.

One to three pages for most small business sites. Long enough to cover goals, pages, features, content and constraints, short enough that someone will read every line. A twenty-page document usually means the important points get lost among the minor ones.

No. Describe what you need the site to do in business terms, for example customers should be able to book a 30-minute consultation and pay a deposit. Choosing how to build that is the developer's job. Naming specific technologies only helps if there is a genuine reason, such as an existing system to connect to.