A website brief is a structured document that describes what you need from a new website, why you need it, and who it is for. It is the document you prepare before you contact developers — and it is the single most useful thing you can do to get a good website at a fair price.
Most web projects go wrong before a single line of code is written. The cause is rarely technical: it is a vague brief. When a business owner tells a developer “I need a modern website,” both sides imagine something different — and the gap between those imaginations becomes delays, extra costs, and disappointment. Preparing a brief before you contact developers will get you faster, more accurate quotes — and it instantly separates serious professionals from guessers. Below is a complete template you can copy, fill in, and send.
In short
- A website brief describes what you need, why, and for whom — before you contact any developer.
- It gives you comparable quotes, fewer surprises, a faster process, and a shared reference when disagreements arise.
- The template has 10 sections: business, goals, audience, scope, content, design references, technical requirements, budget, timeline, and post-launch.
- Two to four pages is the sweet spot: concise answers to the 10 sections usually fit.
- Send it to two or three developers, compare their proposals against your brief — and work with the one who asks the best questions about it.
Contents
- Why does a vague brief cost you money?
- What should a website brief include?
- What does a filled-in mini brief look like?
- With a brief vs without a brief
- What happens after you send your brief?
- What mistakes should you avoid in a brief?
- Checklist: is your brief ready to send?
- FAQ
Why does a vague brief cost you money?
- Comparable quotes. Developers quoting the same brief give you prices you can actually compare. Without one, every quote describes a different project.
- Fewer surprises. Decisions made on paper are cheap; changes made mid-development are expensive.
- Faster process. A developer who receives a clear brief can start productive work immediately instead of spending weeks extracting requirements from you.
- A shared reference. When disagreements arise (they will), the brief is the neutral document you both signed off on.
What should a website brief include?
Work through these 10 sections in order. You do not need polished prose — short, honest answers beat long, vague ones.
1. About your business
Half a page: what you do, who you serve, how long you have operated, and what makes you different. Include your current website (if any) and what you like and dislike about it. A developer who understands your business makes better decisions on your behalf.
2. Project goals (be specific)
Not “a better website” — measurable outcomes. Examples: “generate 15 quote requests per month,” “let customers book appointments online,” “look credible to corporate clients,” “sell our top 50 products online.” Rank them: primary goal, then secondary goals. Everything in the project should serve the primary goal first.
3. Target audience
Describe your ideal visitor: who they are, what they need, how tech-savvy they are, and what device they use. “Homeowners aged 35–60 looking for renovation companies on their phones” leads to very different design decisions than “CTOs evaluating enterprise software on desktops.”
4. Scope: pages and features
List every page or section you need (Home, Services ×4, About, Blog, Contact…) and every feature (contact forms, booking system, online store, multilingual content, client area, integrations with your CRM or email tool). Mark each as must-have or nice-to-have. This single list is what determines most of the quote.
5. Content: who provides what
State clearly who writes the texts, who provides photos and videos, and who supplies logos and brand materials. Content is the number one cause of project delays — usually because nobody agreed upfront who was responsible. If you need the developer to arrange copywriting or photography, say so here.
6. Design references
List 3–5 websites you like and say what you like about each (“the clarity of the homepage,” “the booking flow,” “the overall premium feel”). Also list one or two you dislike and why. This is worth more than paragraphs of adjectives like “modern” or “clean,” which mean different things to everyone.
7. Technical requirements
You do not need deep technical knowledge — just state your constraints: preferred platform (for example, WordPress so your team can edit content), must integrate with specific tools (your booking software, payment provider, CRM), hosting situation (do you have hosting, or should the developer arrange it?), and any compliance needs (accessibility standards, data protection rules).
8. Budget range
Give a range, not a fixed number — and be honest. Developers are not trying to extract your maximum; they are trying to propose the right scope for your investment. A realistic range (for example, €3,000–€5,000) lets them tell you what is achievable and what is not, instead of everyone guessing.
9. Timeline and milestones
Your ideal launch date and any hard deadlines (a trade fair, a seasonal campaign). Also note your own availability: how quickly can you review designs and deliver content? Most delays come from the client side, so plan for your part too.
10. Post-launch: maintenance and training
State that you expect training on managing the site, full ownership of domain, hosting and accounts, and ask for a maintenance proposal. A developer who plans for life after launch is thinking long-term — exactly what you want.
What does a filled-in mini brief look like?
“We are a 12-person accounting firm in Manchester. Goal: generate 10 consultation bookings per month from the website. Audience: small business owners, 30–55, mostly on mobile. Scope: Home, 5 service pages, About, Team, Blog, Contact with booking form; must-have: online booking integration; nice-to-have: client portal. Content: we provide texts (with light editing help), developer arranges stock photography. References: [3 URLs with notes]. Platform: WordPress (we want to publish articles ourselves). Budget: £4,000–£6,000. Launch: before September tax season. Post-launch: training session + maintenance quote.”
One paragraph like that already puts you ahead of most clients developers meet.
With a brief vs without a brief
| With a clear brief | Without a brief | |
|---|---|---|
| Quotes you receive | Comparable: every developer prices the same project | Every quote describes a different project |
| Surprises during the build | Fewer: decisions made on paper are cheap | Changes mid-development are expensive |
| Time to start | Faster: the developer can start productive work at once | Weeks spent extracting requirements from you |
| Disagreements | A shared reference document you both signed off on | No neutral document to settle what was agreed |
| Content delays | Responsibilities agreed upfront | Content becomes the number one cause of delay |
What happens after you send your brief?
Expect serious developers to respond with questions — that is good. They should then return a proposal covering: their understanding of your goals, proposed scope, timeline with milestones, itemised pricing, what is excluded, and post-launch terms. Compare proposals against your brief, not against each other in the abstract.
And if you are considering WordPress as your platform — the most common choice for business sites you can manage yourself — look for a developer who welcomes a detailed brief. The ones who light up when you send one are the ones worth hiring.
What mistakes should you avoid in a brief?
- Copying a competitor’s feature list without knowing which features actually serve your goals.
- Leaving content “for later.” A website without agreed content is a project without an end date.
- Skipping the budget. “Tell me what it costs” without a range produces quotes from €1,000 to €20,000 for the “same” project — useless for deciding.
- Forgetting who decides. If three partners must approve every design, say so upfront so the process accounts for it.
- Treating the brief as final law. It is a starting point for conversation, not a contract carved in stone. Good developers will challenge parts of it — that is a sign of quality, not defiance.
Checklist: is your brief ready to send?
- Does it say what your business does and who it serves, in half a page?
- Does it name one primary goal in measurable terms, with secondary goals ranked behind it?
- Does it describe your ideal visitor, including the device they use?
- Does it list every page and feature, marked must-have or nice-to-have?
- Does it say who provides texts, photos, videos, and brand materials?
- Does it include 3–5 design references with notes on what you like about each?
- Does it state your platform, integrations, hosting situation, and compliance needs?
- Does it give an honest budget range and an ideal launch date?
- Does it ask for training, full ownership, and a maintenance proposal?
FAQ
How long should a brief be?
Two to four pages is the sweet spot. Shorter and it is vague; longer and nobody reads it carefully. The 10 sections above, answered concisely, usually fit.
What if I don't know what I need technically?
That is fine — and normal. Describe your business problem and goals; a good developer translates them into technical solutions. The brief captures what you know (goals, audience, content, budget); the developer fills in the how.
Should I send the brief to multiple developers?
Yes — two or three. It lets you compare approaches and prices fairly, and you will learn a lot from how differently professionals interpret the same document.
What if my budget is very small?
Say so honestly. A good developer will propose a phased approach: launch the essentials now (a solid small site), add features later as the business grows. What is not honest — on either side — is pretending a €800 budget buys a €8,000 project. Phasing beats cutting corners.
Can I write the brief together with the developer?
Absolutely — many of the best briefs are co-created in a paid discovery session. You bring the business knowledge, the developer brings the digital experience, and together you produce something better than either would alone. If a developer offers this, take it.
Ready to hire a developer?
Prepare your brief with the 10 sections above, then send it to a developer who welcomes detail. If you would like help turning your brief into a website, contact us or message us on WhatsApp — and send your brief with your first message. It will make the conversation faster, clearer, and easier for both sides.