The single biggest predictor of a smooth web project isn't the technology, the budget, or the developer's skill. It's the brief. A clear brief gets you accurate quotes, realistic timelines, and a finished product that matches your expectations. A vague brief gets you guesswork, scope creep, and frustration on both sides.
Writing a good brief doesn't require technical knowledge. It requires clarity about what you want and why. Here's how to structure one that gets results.
A strong brief covers these ten components:
- •1. Who you are — business overview, industry, and size
- •2. Your goals — measurable outcomes the site should achieve
- •3. Your audience — who will use the site and how
- •4. Functional requirements — what the site must do
- •5. Non-functional requirements — performance, accessibility, compliance
- •6. Visual references — sites you admire with notes on why
- •7. Technical preferences — existing systems or platform constraints
- •8. Timeline — deadlines, milestones, and flexibility
- •9. Budget range — a realistic range to right-size the solution
- •10. What's out of scope — what you're not expecting the developer to handle
1. Start with Who You Are
Give a short overview of your business. What do you do? Who do you serve? What problem do you solve? This isn't fluff — it's context. A developer who understands your business will make better decisions than one working in the dark.
Include your industry, your rough size (sole trader, 10-person team, 200 employees), and any relevant background. If you've had a website before, mention what worked and what didn't.
2. Define Your Goals
What should this website achieve? "We need a new website" isn't a goal. "We want to generate 20 qualified leads per month" is. "We want to reduce phone enquiries about opening hours by 50%" is. "We want to sell products online and hit £10,000/month in revenue within six months" is.
Measurable goals give the developer something to design towards. They also give you a way to judge whether the project was successful after launch.
3. Describe Your Audience
Who will use this website? Be specific. "Everyone" is not a useful answer. Are they young professionals researching on their phones during commutes? Property developers comparing agencies on their laptops? Parents looking for local childcare at 11pm?
Understanding who your users are shapes everything — the design, the content structure, the features, even the tone of voice. The more detail you provide here, the better the end result.
4. List What It Must Do
These are your functional requirements — the things the website needs to actually do. Think in terms of actions: display a portfolio, take online bookings, process payments, show a live calendar, integrate with your CRM, let users filter products by category.
Be thorough. If you forget something at this stage, it'll surface later as a change request — and that usually means extra cost and delays.
5. Mention Non-Functional Requirements
These are the qualities your site needs to have, rather than specific features. How fast should it load? Does it need to handle thousands of simultaneous users? Are there accessibility standards you need to meet? Compliance requirements like GDPR?
You don't need to specify exact metrics, but flagging these concerns early helps the developer choose the right approach from the start.
6. Share Visual References
Show, don't just tell. Collect three to five websites you admire — competitors, brands in other industries, anything that captures the feel you're going for. For each one, note what specifically you like. Is it the layout? The colour palette? The way they present their services?
If you have rough sketches, wireframes, or even napkin drawings of how you imagine key pages, include them. They don't need to be polished — they just need to communicate your thinking. Visual references accelerate the estimation process enormously because they reduce ambiguity.
7. Note Any Technical Preferences
If you have existing systems the website needs to integrate with — a booking platform, an email marketing tool, an accounting package — list them here. If you have a strong preference for a particular platform (WordPress, Shopify, custom-built), mention it, along with why.
If you don't have technical preferences, that's perfectly fine. In fact, it's often better. Let the developer recommend the right approach based on your requirements rather than constraining them to a specific technology.
8. Set Out Your Timeline
When do you need the site live? Is there a hard deadline (a product launch, a rebrand, a seasonal peak) or is it flexible? Are there milestones along the way — design approval by a certain date, content ready by another?
Be realistic. A custom website typically takes 8 to 16 weeks from kickoff to launch. If your timeline is tighter than that, say so upfront — it affects how the work is scoped and priced.
9. Include a Budget Range
This is where most people hesitate, worried that sharing a budget means the developer will spend every penny of it. In reality, the opposite is true. Knowing your budget lets a developer right-size the solution. Without it, they're guessing — and they might propose something far above or below what you had in mind, wasting everyone's time.
You don't need to give an exact figure. A range is fine: "We're thinking £10,000 to £20,000" or "Our absolute maximum is £15,000." This helps filter out developers who can't work at your level and helps the right ones propose something that fits.
10. Define What's Out of Scope
This is the one most people forget, and it's arguably the most important. If you're not expecting the developer to write your copy, say so. If photography is being handled separately, note it. If you don't need e-commerce right now but might want it later, clarify that.
Defining what's out prevents the most common source of project friction: mismatched expectations about what's included. It protects both you and the developer.
The Golden Rule: What and Why, Not How
Focus on what you need and why you need it — not how it should be built. That's what you're paying the developer for.
Throughout your brief, focus on what you need and why you need it. Resist the urge to specify how it should be built. "We need users to be able to book appointments" is useful. "We need a React-based booking widget with a PostgreSQL backend" is not — unless you have a genuine technical reason for that constraint.
Let the developer propose the technical approach. That's what you're paying them for. Your job is to paint a clear picture of the destination. Their job is to find the best route.
| Good Brief | Bad Brief |
|---|---|
| We need users to book appointments online | Build a React booking widget with PostgreSQL |
| The site should load in under 2 seconds | Use Cloudflare and Nginx with HTTP/2 |
| We want to rank for "plumber in Manchester" | Do SEO on the site |
| Our budget is £8,000–£12,000 | Make it as cheap as possible |
| Photography is handled separately | (No mention of content responsibility) |
What a Good Brief Gets You
A well-written brief typically takes two to three hours to put together. In return, you get quotes that are accurate rather than padded with contingency. You get proposals that address your actual needs. You get fewer surprises during the project. And you get a finished product that looks like what you asked for — because you asked for it clearly.
The better your brief, the more accurate your quote, and the less back-and-forth during the build. That's time and money saved for everyone.