A website project brief is a short document, usually two to five pages, that tells a developer what your site is for, who it serves, what it must do, what content exists, and your budget, deadline and constraints. It is written by you, in plain language, before you ask for quotes.
A clear brief lets several firms quote the same project, cuts days out of discovery and surfaces misunderstandings while they are still cheap. The template below can be copied section by section; fill in what you know and write "unknown" for the rest.
What is a website project brief, and how is it different from a requirements document?
A brief explains the why and the what from the business side. A website requirements document, or scope of work, is the detailed specification of how it will be built, usually written by the developer after discovery and agreed by both sides.
A web design brief is a narrower version focused on look, brand and user experience. For most small and mid-size projects, one good project brief covers the design side too, and the developer turns it into the requirements document.
What should a website brief include?
A complete brief answers twelve questions, which match the template sections below:
- What is the project and who decides?
- What should it achieve, and how will you measure that?
- Who is it for?
- What exists today that should be kept, fixed or removed?
- Which pages does it need?
- Which features, and how important is each?
- Who provides the content?
- How should it look and feel?
- What must it connect to, and what rules apply?
- What are the budget and timeline?
- What happens after launch?
- What do you want back from the firms you send it to?
The website brief template (copy this)
Copy everything from here to the end of section 12 into a document and answer each prompt. Short answers are fine.
1. Project summary
- Business name and what you do, in one sentence:
- Project type: new website, redesign, online store or web application
- Current website address, if any:
- Day-to-day contact, and the person who makes final decisions:
- This project is a success if:
2. Goals and how you will measure them
- Primary goal, for example more qualified enquiries, online sales or fewer phone calls asking the same questions:
- Secondary goals:
- How you measure this today, and the current number if you know it:
- Where you want that number to be 6-12 months after launch:
3. Audience
- Main customer types, in order of importance:
- What each needs to find or do on the site:
- Countries, languages and devices they use:
- Questions they usually ask before buying:
4. Current site: keep, fix, remove
- Pages or features that work well:
- What frustrates you or your customers:
- Pages that bring in search traffic, from Google Search Console or analytics:
- Content to move across, and roughly how many pages or posts:
5. Pages
- List every page or section you expect, for example Home, About, each service, Pricing, Blog, Contact, Privacy policy:
- Pages you are unsure about:
6. Features and functionality
Mark each feature Must (cannot launch without it), Should (important, could follow shortly after) or Could (nice to have). Replace the examples with your own.
| Feature | Details | Priority | Notes |
|---|---|---|---|
| Contact form | Sends to the sales inbox and creates a lead in our CRM | Must | CRM is HubSpot |
| Online booking | Customers choose a time slot; syncs with Google Calendar | Should | Two staff calendars |
| Online payments | Card payments, plus eSewa and Khalti for Nepal | Must | Merchant accounts not yet open |
| Blog | Staff publish one post a week | Should | Two editors |
| Second language | Nepali and English versions of key pages | Could | Could be phase two |
| Customer login | Customers view past invoices | Could | Phase two |
| Newsletter signup | Adds subscribers to our Mailchimp list | Should | Needs consent checkbox |
7. Content
- Who writes the copy: you, the developer, or a copywriter?
- Photos: existing, a new shoot or stock?
- Video, downloads or other media:
- Product or service data: how many items, and where does it live now?
- Who approves content before it goes live?
8. Design and brand
- Brand guidelines, logo files in vector format, colors and fonts:
- Three websites you like, and exactly what you like about each:
- Websites you dislike, and why:
- Three words for how the site should feel:
- Accessibility target (WCAG 2.2 level AA is a sensible default):
9. Technical requirements and integrations
- Preferred platform, or "no preference":
- Who will edit the site, and how often?
- Systems to connect: CRM, email marketing, accounting, booking, inventory, payment gateways:
- Who holds the domain, hosting and email accounts today?
- Analytics and tracking: GA4, Tag Manager, ad conversion tags:
- Legal and privacy requirements, for example cookie consent under UK GDPR and PECR, the Australian Privacy Act 1988 or Nepal's Individual Privacy Act 2075:
- Performance target, for example passing Core Web Vitals on mobile:
10. Budget and timeline
- Budget range for the build:
- Budget for monthly running costs:
- Hard deadline, and the reason for it:
- Could the site launch in phases?
- Holidays or busy seasons when your team is unavailable:
11. After launch
- Who will maintain and update the site?
- Training needed for your editors:
- Ongoing work you expect, such as SEO, content or ads:
- Ownership: code, repository, domain, hosting and licences must be in our name.
12. What we would like back from you
- Proposed scope, including what is excluded
- Timeline with milestones and what you need from us
- Price and payment schedule
- Who would work on the project
- Examples of similar work
- Any questions about this brief
How much detail is enough?
Enough that two firms reading it would quote roughly the same project. For a small business site that is often two pages; for a store or web application, closer to five. Longer is not better if the extra length is feature wish-lists rather than decisions.
Describe problems rather than prescribing solutions. "Customers keep phoning to ask whether we have stock" leads to a better answer than "we need a chatbot", because the developer can suggest a simpler fix, such as showing stock levels on product pages.
Common mistakes in a web design brief
- No budget. Without a range, firms guess, and you get quotes for three different projects.
- Everything marked "must". If every feature is essential, nothing can be trimmed when the quote comes back high.
- Vague style words. "Modern and clean" describes most websites; name real examples instead.
- Forgetting content. Late content is one of the most frequent reasons projects stall; say who is writing it.
- Hiding the awkward parts. If a former developer holds the domain, or a system has no API, say so upfront.
- Too many approvers. List who signs off. Unexpected approvers late in the project cause rework.
What happens after you send the brief?
Send the same brief to two to four firms and give them a week to ask questions. Share every answer with all of them so the quotes stay comparable. The questions a firm asks tell you a lot about how it would run the project.
When proposals arrive, our guide to comparing web development quotes shows how to line them up, and how long it takes to build a website will help you judge whether their timelines are realistic. If you are unsure whether you need a site or something closer to software, read website vs web application before you send it.
How Meritbyte uses your brief
Meritbyte Technologies is a Nepal-based web and software development company, and a brief like this is the best way to start a conversation with us. A person replies within one business day. After a free scoping conversation, you get back a scope, a timeline and a number, with no paid discovery phase in between.
The first milestone is fixed-price, and the brief becomes the checklist we both measure it against. Our web development, website design and UI/UX design pages explain what each part of a build covers. Small businesses can also start with a free website design idea, or send us the brief directly.
Frequently asked questions
How long should a website brief be?
Usually two to five pages. A small business site can be briefed in two pages if the goals, pages, features, content responsibilities, budget and deadline are clear. Online stores and web applications need more detail on features, integrations and data. The test is whether two different firms reading it would quote roughly the same project, not the page count.
Should I include my budget in a website brief?
Yes. A budget range lets firms recommend the right approach for your money, such as a well-built theme instead of a fully custom design, or a phased launch. Without it, you receive quotes for very different projects that cannot be compared. Giving a range does not mean firms will simply quote the maximum; good ones will explain what fits within it.
What is the difference between a brief and a scope of work?
The brief is written by you and explains goals, audience, needs and constraints in business language. The scope of work, or requirements document, is written by the developer after discovery and specifies exactly what will be built, what is excluded, and how success is tested. The brief is the starting point for the scope, and both should be kept together.
Do I need a brief for a small website?
Yes, even a one-page one. A short brief covering goals, pages, who writes the content, budget and deadline prevents the most common problems on small projects: mismatched expectations, stalled content and quotes that cannot be compared. It takes an hour or two to write and usually saves far more time than that during the build.