A website brief tells a developer what the site is for, who uses it and what must work. Written well, it gets you comparable quotes and fewer surprises.
A website brief is a one to three page document that tells a developer what the site is for, who will use it, which pages and features you need, what content you will supply, and your deadline and budget. You do not need to name any technology. Describe the outcome you want and let the developer recommend the tools.
What a website brief is and why it matters
A website brief is a short written description of the project that you give a developer before they quote. It says what the site is for, who will use it, what it must contain and what you will supply. Developers use it to estimate the work. Without one, each team makes its own assumptions, and you end up comparing quotes that cover different things.
A brief is not a technical specification. You are not expected to choose a platform, a database or a hosting plan. Your part is to describe the business problem and the practical details that only you know. The developer's part is to propose how to build it.
Writing the brief also helps you. Questions that feel small, such as who writes the text or who approves changes, are cheaper to settle on paper than halfway through a build. The article on website development stages and who does what shows where the brief sits in the wider process.
What a website brief should include
Use the headings below in this order. Each has a short prompt. Answer in plain sentences or short lists. If you do not know an answer, write "not sure" instead of skipping it, because that tells the developer where to ask.
1. About the business
Write two or three sentences on what you sell, who buys it and how customers find you today. If you have a site already, give its address and say what you like and dislike about it.
2. The purpose of the site
Pick one main goal and no more than two supporting ones. Examples are getting enquiries from local homeowners, taking orders for a product range, or giving existing customers a place to find information. A goal such as "look professional" is too vague to design for. Say what a visitor should do: fill in a form, call, book or buy.
3. Who will use it
Describe the two or three kinds of visitor, what each wants to find and which device they probably use. A shop's visitors may arrive mostly on phones, while a business that sells to companies may see more office desktops. If you have no data, say what customers tell you in conversation.
4. Pages and structure
List the pages you expect, even if the names change later: home, services, about, contact and so on. Mark which pages must exist at launch and which can follow. If the old site has pages that bring in visitors, say whether their addresses should stay the same.
5. Features and integrations
List anything the site must do beyond showing pages: enquiry forms, online payments, booking, a login area, a product catalogue, a map, a WhatsApp chat link, a connection to your accounting or customer software, a newsletter signup. Mark each one as must have, should have or nice to have. This single step lets a developer price options, and lets you drop an item without asking for a new quote.
6. Content
Say who will write the text, supply the photographs and provide the logo, and by what date. If you expect the developer to write copy, say so. Late content is one of the most common reasons a project slips, so write dates down.
7. Look and feel
Give two or three websites you like, from any industry, and say what you like about each: the layout, the colour, the tone or the simplicity. Add one you dislike and say why. Attach your logo and brand colours if you have them. If you have not settled a brand yet, say so, because it changes the design work.
8. Technical and ownership details
Write down what already exists: your domain name and who registered it, any hosting, the platform of the current site, your email system and who holds each login. Say if you need to edit pages yourself after launch, and how often. Mention any software the site must connect to. If you know none of this, say that. The guide to preparing for a website or app handover explains why owning these accounts is important.
9. Search visibility
If you want the site found on Google, name the services and places that matter. If the current site already gets visitors, ask for its page addresses to be kept or redirected so you do not lose that traffic. Say whether Google Search Console and an analytics tool are already set up.
10. Timeline, budget and decisions
Give a launch date only if a real event drives it, such as a shop opening or a campaign. Name who approves work and how long you need to give feedback. Then state your budget position, as the next section explains.
Should you name a budget in the brief?
In most cases, yes, as a ceiling or a range. A website can be built at very different levels of depth, so a developer who does not know your limit has to guess. The proposal may then be out of reach, or it may leave out things you would have paid for. Naming the budget lets them propose something that fits.
Some owners worry that the developer will simply spend the whole amount. Two habits reduce that risk. Ask for the proposal to price items separately, so you can see what each part costs. And ask for options: a core version, plus extras you can add later.
If you truly cannot give a figure yet, rank your features by priority and ask each developer to explain what moves the price. Whatever you decide, do not hide the budget and then judge quotes on price alone.
How long should a website brief be?
For a brochure site of a handful of pages, one to two pages is enough. A shop, a booking system or a site with logins usually needs three to five, because features take more words to describe. If it runs longer, move the detail into attachments: a page list in a spreadsheet, brand files, and screenshots of sites you like.
A developer reads a short, specific brief closely and skims a long one. Cut any sentence that would not change what gets built or quoted.
A short example
The paragraph below is an invented example for a small dental clinic. It shows the level of detail that works.
We run a small dental clinic with two dentists and a reception team. Most new patients find us through Google Maps or a recommendation. Our current site is old, hard to edit and slow on phones. The new site should make it easy for a new patient to see our treatments, check opening hours and request an appointment by form or phone. Must have: a page for each treatment, a page for each dentist, an enquiry form, a map and opening hours. Should have: a patient FAQ. Nice to have: online booking. We will supply all text and photographs by a date we will agree. The practice manager approves all work and gives feedback in one round.
The example names no platform, no plugin and no design details beyond the goal. It still gives a developer enough to ask sensible follow-up questions.
Do you need to know the technology?
No. Describe what the site must do and what you already own or use, then ask the developer to recommend a platform and explain why. A good answer names the trade-offs: who can edit the site, what it costs to run each year, how well it can grow, and what happens if you later change developer.
Two questions are worth asking whatever the answer. Will the domain and hosting be registered in my name? Can I edit the pages I expect to change?
What happens if your requirements change?
They will change to some extent. Seeing a first layout often shows you something you had not thought of, and that is normal. The problem is unmanaged change, where extra work is agreed in conversation and nobody records what it does to time and cost.
Agree a method before the build starts.
- Treat the brief as version 1 and put a date on it.
- Ask how the developer handles a change request, and whether small adjustments during design are already included.
- Write each change down, and ask for its effect on timeline and cost in writing before you approve it.
- Keep a separate "later" list for ideas that are not essential at launch, so they are not lost and do not delay the launch.
- Name one person who can approve changes, so the team never receives conflicting instructions.
Some changes are cheap early and expensive late. Rewording a page costs little at any stage. Changing the structure of the site, or how products are organised, after design and build have started can mean redoing work. Settle the page list and the must-have features first, and leave wording and fine visual detail for the later rounds.
Before you send the brief
- Ask someone outside the business to read it and tell you what the site is for. If they cannot, rewrite the purpose section.
- Check that every must-have feature appears in the page list, and the other way round.
- Send the same brief to every developer you speak to, so the quotes can be compared on one basis.
- Ask each one to reply with questions before they quote. The questions show how closely they read it.
When the replies arrive, look for a developer who restates your goal in their own words, lists what they have assumed and says what they would leave out. That developer has read the brief. One who sends a generic proposal has not. Once you have a shortlist and want to talk through a project, the website development page describes what Liftup builds for businesses.
Questions and answers
What should a website brief include?
A good brief covers the business, the main goal of the site, the visitors, the pages and features you need, who supplies the content, the look you want, what you already own technically, and your deadline and budget position. Rank features as must have, should have or nice to have so the developer can price options.
How long should a website brief be?
One to two pages is enough for a small brochure site. Shops, booking systems and sites with logins usually need three to five pages. Put extra detail in attachments such as a page list or brand files, because a short brief is read more closely than a long one.
Should I name a budget in the brief?
Usually yes, as a ceiling or a range. It stops the developer guessing and lets them propose something that fits. Ask for items to be priced separately and for optional extras, so you stay in control of what you spend.
Do I need to know the technology to write a brief?
No. Describe the outcome you want and the facts you know, such as your domain, current site and who holds the logins. Ask the developer to recommend a platform and explain the trade-offs, including who can edit the site and who owns it.
What happens if my requirements change?
Small changes during design are normal. Agree beforehand how change requests work, write each one down and ask for its effect on time and cost before approving it. Keep a separate list for later ideas, and settle the page list and key features before the build starts.
Should I send the same brief to several developers?
Yes. Using one brief lets you compare quotes on the same basis, and the questions each developer asks tell you how well they understood the project. Treat a reply that ignores parts of the brief as a warning sign.