There's a document that exists at the start of every website project. Most clients get it wrong. Most developers learn to expect it to be wrong.
It's the brief.
Not the contract (that comes later). Not the wireframe (that's the developer's job). The brief is the short document where you explain what you want, who it's for, and why it matters.
When it's done well, it saves weeks of back-and-forth. When it's done badly, it's the beginning of a project that goes sideways for months.
Here's how to write a brief that actually helps.
Why most briefs fail
The common mistake is treating a brief as a wishlist.
Clients write things like:
- "I want a modern, clean design"
- "Something like [competitor's site] but better"
- "Mobile-friendly with lots of features"
These aren't briefs. They're opening shots in a negotiation the developer can never win, because they don't describe what the site is for. They describe what it should look like, which is the last decision, not the first.
A good brief does the opposite. It explains the business context, and lets the developer propose the design.
The rule: briefs should answer why and what, not how.
The six things a good brief covers
Every brief worth its name covers these six things. Each one can be a paragraph or a page — but all six need to be in there.
1. What the business does
One paragraph. Not a sales pitch — a straight description.
"Coastal Coffee is a small roastery in Devon that sells beans online and operates one café. We've been open for 4 years and currently sell around £3,000/month online."
That's a brief. Now the developer knows:
- The scale of the business
- What the site needs to support
- Whether e-commerce matters, and how much
- The likely budget range
- The geography
Compare it to: "We're a passionate coffee brand bringing quality to our community." That's a paragraph of marketing copy. It tells the developer nothing.
2. Who you're trying to reach
Who is the website for? Not "everyone" (it's never everyone). Not "people who love coffee" (too vague).
Something like:
- "Home coffee enthusiasts, 25–45, who already buy specialty beans online"
- "Small cafés and restaurants looking for wholesale supply"
- "People who've visited our café and want to keep in touch"
Different audiences need different websites. A wholesale-focused site looks nothing like a consumer-focused one. Knowing the audience shapes every decision.
3. What success looks like
If the website works perfectly, what happens?
Be specific:
- "We get 20 wholesale enquiries a month"
- "Customers can buy beans directly without emailing us"
- "Our regulars sign up for a newsletter that keeps them coming back"
- "People find us through Google when they search for 'coffee roastery Devon'"
Each of these implies a different site structure. Without this, the developer is building a site with no goal.
4. What you currently have
Any existing website, social media, or online presence.
Include:
- Current URL (if any)
- What's working about it
- What's not working about it
- Any analytics if you have them
If you have a site with traffic data, share the numbers. "We get 500 visitors a month" tells the developer more than "we want more traffic."
5. What's non-negotiable
Every project has constraints. Name them upfront.
Common constraints:
- Budget (a range, not a number)
- Timeline (a date you actually need it by, not a wish)
- Specific features you must have
- Existing tools that must integrate
- Brand guidelines you must follow
- Accessibility requirements
Hiding constraints is how projects get abandoned halfway through. "We didn't know you needed X" is a conversation that should happen at the start, not at delivery.
6. What you're specifically worried about
This is the most useful part of a brief and the most commonly left out.
Every client has a fear about the project. Name it.
Examples:
- "I'm worried I'll pay for a site nobody can update"
- "I've had a bad experience with a previous developer"
- "I'm not sure if I need e-commerce yet, but I want the option"
- "I don't know how to write copy and I'm worried it'll slow things down"
A good developer reads this section carefully because it tells them what to be extra careful about. A developer who ignores it is going to build something generic.
What a brief shouldn't include
Just as important — what to leave out.
Design direction. Don't specify colors, fonts, or layout. You can mention reference sites ("we like the feel of [x]"), but don't prescribe design. That's what you're hiring a designer for.
Technical specifications. Don't say "we need a React site deployed on Vercel." You might not know what you need. Say what the site needs to do, and let the developer choose the tools.
A full feature list. Don't list 40 features in the first brief. Focus on the 5–10 that actually matter. If you list everything, the developer will think you're overcommitting and quote accordingly.
A hidden agenda. Don't include requests that aren't part of the project (like asking for free advice, or asking about "just one small extra thing"). Briefs should be honest.
A template you can actually use
Here's a template that covers the six sections. Copy it, fill it in, and you'll have a better brief than 80% of clients.
That template covers everything in under 200 words. A brief doesn't need to be longer.
What happens after you send it
A good developer will:
- Read the whole thing
- Ask follow-up questions (a sign they're taking it seriously)
- Come back with a proposal that addresses your concerns
- Clarify anything ambiguous before starting
A bad developer will:
- Reply with a price immediately
- Not ask any questions
- Not reference the brief in their response
The response to your brief tells you almost as much about the developer as the developer tells you.
What to do if you don't know some of the answers
Write it in the brief:
- "I don't know what success looks like yet — I'd like your input on this"
- "I haven't set a budget yet — what's typical for this kind of project?"
- "I'm not sure who my audience is — the site needs to serve both [A] and [B]"
Good developers will help you figure out what you don't know. Bad ones will quote based on the brief alone and disappear.
A brief doesn't need to be complete. It needs to be honest about what's in it and what's missing.
Why this matters
The brief is the foundation of the entire project. Every decision after this — design, development, testing, launch — depends on what you put in it.
A great brief makes a project feel almost easy. A bad one makes it feel like a fight.
The hour you spend writing a good brief saves you ten hours of revision requests later.
The uncomfortable truth
Most website projects that fail were doomed by the brief.
Not because the developer was bad. Not because the client was difficult. Because neither side understood what they were actually building until it was too late to change course.
The brief is the one chance you get to prevent that.
Take it seriously.
Ready to hire someone? Read our 10 questions to ask before hiring a web developer. Or if you're comparing options, start with freelancer vs agency.
