How to write a website brief a developer can quote from

A good website brief tells a developer what your business does, who the website is for, what it must do and what limits apply, in enough detail that they can give you an accurate quote. It does not need technical language. This guide explains each section and ends with a website brief template you can copy and fill in.

A brief is a short written document, usually a few pages, that describes your website project before any design or code begins. Developers use it to understand the job, estimate the work and ask better questions. If you would like to see how we approach website projects, our website service page explains our process.

Why a clear brief saves money

Most budget surprises in website projects come from misunderstandings at the start, not from technical problems later.

• Quotes become comparable. When every developer reads the same brief, their quotes describe the same project. Without one, you may compare a simple site with a complex one without realising it.
• Fewer changes mid-project. Features discovered halfway through the build cost more than features planned from the start.
• Faster start. A developer who understands your goals can move to design sooner, with fewer meetings.
• Better decisions. Writing the brief forces useful internal conversations, such as who approves the design and which pages really matter.

The brief is not a contract and does not need to be perfect. Its job is to make everyone's assumptions visible.

If you are replacing an existing site, our guide to the website redesign process explains how to review it before writing the brief.

Goals and audience

Start with why the website exists and who it serves. This section guides every later decision, from page structure to design.

1. Describe your business in a few sentences. What you sell, where you operate and what makes you different.
2. State the main goals. Examples include getting enquiries, selling products online, taking bookings, recruiting staff or answering customer questions. Rank them, because the top goal shapes the home page.
3. Describe your audience. Who visits, what they want to find, and what they need to see before contacting you. Include any differences between groups, such as new customers and existing clients.
4. Define success. How will you know the website is working? More enquiries, fewer support calls or online sales are all measurable goals.
5. Explain what is wrong with the current site, if you have one. Be specific: slow, hard to update, not working on phones, or not bringing in enquiries.

Writing goals a developer can use

Vague goals lead to vague websites. Compare these two ways of describing the same aim:

• Vague: "We want a professional website that attracts customers."
• Useful: "We want small business owners in our city to request a quote for office cleaning. The home page should explain our services, show the areas we cover and make the quote form easy to find on a phone."

The second version tells a developer who the visitor is, what they should do, and which pages and features matter most. It also gives the designer a clear idea of what to put first. You do not need marketing language; plain, specific sentences work best.

If you have more than one type of visitor, write a short goal for each. For example, a clinic might want new patients to book a first appointment, while existing patients mainly need opening hours and contact details.

Pages, features and content

This is the section developers read most closely, because it drives most of the effort.

1. List the pages. A simple list is enough: home, about, services, individual service pages, contact, blog, privacy policy. Mark which pages exist today and which are new.
2. List the features. Contact forms, online booking, payments, a customer login, a searchable catalogue, multiple languages or a newsletter sign-up. For each, say briefly what it should do.
3. Name any integrations. An integration connects your website to another system, such as your CRM (customer relationship management software), booking system, accounting tool or email marketing service. Name the tools you use.
4. Say who will update the site. If your team will edit pages, add blog posts or change prices, the site needs an easy admin area. Say who will use it and how often.
5. Explain the content situation. Who writes the text and provides photos? Is existing content being reused? Content is one of the most common reasons launches are delayed, so be honest here.
6. Mention search and legal needs. Note whether search engine optimisation (making the site easy for search engines to understand) is part of the job, and whether you need cookie notices, accessibility work or specific legal pages in your market.

Separate your list into "must have at launch" and "can come later". This single step often makes the first phase smaller, cheaper and faster.

Describing features clearly

For each feature, a few plain sentences are enough. Describe who uses it, what they do and what should happen next. For example:

"Visitors can book a consultation. They choose a service, pick an available time from our calendar and enter their name, email and phone number. They receive a confirmation email, and our office receives a notification. Staff can see and cancel bookings in an admin area."

This kind of description answers most of a developer's questions before they ask them. It also shows hidden work, such as the confirmation email and the admin area, that might otherwise be missed in a quote. If a feature has rules, such as bookings only on weekdays or a minimum notice period, write them down too.

If your feature list includes accounts, bookings or dashboards, our comparison of a website and a web application helps you describe what you need.

Examples you like and dislike

Words like "modern" and "clean" mean different things to different people. Examples remove the guesswork.

1. Share a few websites you like. They do not need to be in your industry. For each, say what you like: the layout, the colours, how easy it is to find information, or how the booking works.
2. Share a few you dislike, and why. This is often more useful than the likes, because it tells the designer what to avoid.
3. Provide your brand materials. Logo files, colours, fonts and any brand guidelines. If you do not have these, say so, as the project may need to include some branding work.
4. Describe the tone. Formal or friendly, technical or plain, playful or serious. A sentence or two is enough.
5. Mention your competitors. Name a few businesses you compete with and say how you want to look different from them. A developer can then check their websites and avoid making yours look the same.

Screenshots with short notes are often clearer than long descriptions. A folder of examples, each labelled with what you like or dislike, gives a designer a useful starting point for the first meeting.

Budget, timeline and decision makers

Many people leave budget out of a brief, hoping for a lower quote. In practice, sharing a range helps developers suggest the best solution for what you can spend, rather than guessing.

1. Share a budget range. It helps a developer suggest what fits, and what should wait for a later phase.
2. Give your timeline. Include any fixed dates, such as a product launch or event, and explain why they matter.
3. Name the decision makers. Say who gives feedback and who has final approval. Projects slow down when approvals are unclear or when a new person joins late with different views.
4. Describe what happens after launch. Do you want ongoing maintenance, hosting, content updates or search engine work? This affects how the site is built.
5. List practical details. Who controls the domain name and current hosting, and whether any email accounts depend on them.

Our website launch checklist shows the final checks to allow time for in your timeline.

A simple website brief template you can copy

Copy this website brief template into a document and fill in each section. Short answers are fine; clarity matters more than length.

WEBSITE BRIEF

1. About the business
   What we do:
   Where we operate:
   What makes us different:

2. Goals
   Main goal:
   Other goals, in order:
   How we will measure success:

3. Audience
   Who visits the site:
   What they need to find or do:

4. Current website (if any)
   Address:
   What works:
   What does not work:

5. Pages
   Must have at launch:
   Can come later:

6. Features and integrations
   Features (with a short description of each):
   Tools the site must connect to:
   Who will update the site, and how often:

7. Content and brand
   Who provides text and photos:
   Brand materials available:
   Tone of voice:

8. Examples
   Sites we like, and why:
   Sites we dislike, and why:

9. Budget, timeline and approvals
   Budget range:
   Target launch date, and why:
   Who gives feedback:
   Who gives final approval:

10. After launch
    Hosting, maintenance or other ongoing support needed:

Once the brief is written, share the same version with every developer you contact. Ask each one to list questions and assumptions with their quote. The questions they ask are often the best sign of how carefully they read it.

Common mistakes to avoid

A few problems appear in briefs again and again:

• Listing features without purpose. "We need a blog" is less useful than "we want to publish guides that answer customer questions".
• Leaving content to the end. If nobody owns writing the content, the finished site waits for it.
• Hiding the budget. It leads to proposals that do not fit, and a second round of quotes.
• Too many decision makers. Feedback from many people with no final approver slows everything down.
• Assuming the developer knows your industry. Explain terms and processes that are obvious to you but may not be to an outsider.

When you are ready to compare prices, our guide to how much a business website costs explains what drives the numbers in each quote.

Summary

• A brief makes assumptions visible and quotes comparable.
• Start with goals, audience and what success looks like.
• List pages and features, split into "at launch" and "later", and be honest about content.
• Use examples you like and dislike to explain design preferences.
• Share a budget range, timeline and who approves decisions.

A clear brief is the cheapest improvement you can make to any website project. If you have a brief ready or want help shaping one, you can send it to us here.