Most web projects go wrong before a single line of code is written. The cause is rarely technical: it’s 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.
A website brief is simply a structured document describing what you need, why, and for whom. Preparing one before you contact developers will get you faster, more accurate quotes — and instantly separates serious professionals from guessers. Below is a complete template you can copy, fill in, and send.
Why a brief saves 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.
The template: 10 sections to complete
1. About your business (half a page)
What you do, who you serve, how long you’ve 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, 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, 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, client area, integrations with your CRM or email tool). Mark each as must-have or nice-to-have. This single list is what determines 80% 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 #1 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 don’t need deep technical knowledge — just state your constraints: preferred platform (e.g., 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 aren’t trying to extract your maximum; they’re trying to propose the right scope for your investment. A realistic range (“€3,000–€5,000”) lets them tell you what’s achievable and what isn’t, 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/accounts, and ask for a maintenance proposal. A developer who plans for life after launch is thinking long-term — exactly what you want.
Example: a filled-in mini brief
“We are a 12-person accounting firm in Manchester. Goal: generate 10 consultation bookings/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 90% of clients developers meet.
Common brief mistakes to avoid
- 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’s a starting point for conversation, not a contract carved in stone. Good developers will challenge parts of it — that’s a sign of quality, not defiance.
What happens after you send it
Expect serious developers to respond with questions — that’s good. They should then return a proposal covering: their understanding of your goals, proposed scope, timeline with milestones, itemized pricing, what’s excluded, and post-launch terms. Compare proposals against your brief, not against each other in the abstract.
And if you’re considering WordPress as your platform — the most common choice for business sites you can manage yourself — read why WordPress works for businesses, and when you’re ready, talk to a WordPress developer who welcomes a detailed brief. The ones who light up when you send one are the ones worth hiring.
FAQ
How long should a brief be?
Two to four pages is the sweet spot. Shorter and it’s 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’s 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’ll 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’s 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.