OnWebPoint 
Table of Contents
“Make it look modern and professional, with a pop of colour” is, word for word, the most common brief a web developer receives. It is also almost entirely useless. Learning how to brief a web developer properly is one of the most underrated things a business owner can do before starting a website project — a good brief takes thirty minutes to write and saves weeks of revisions, confusion, and mismatched expectations later.
Why Learning How to Brief a Web Developer Saves Time and Money
Vague briefs produce vague quotes. When a developer cannot tell from your brief what the site needs to actually do, they either quote high to cover uncertainty, make assumptions that turn out to be wrong, or both. The projects that overrun, go over budget, or end in frustration almost always started with a brief that described aesthetics rather than goals. Knowing how to brief a web developer shifts the entire dynamic — you get more accurate quotes, fewer “that’s not quite what I meant” moments, and a faster build.
What a Good Brief Actually Needs
1. What the Website Needs to Do
Not “look good” — what action should it drive? Phone calls, quote requests, online bookings, product sales, job applications. Everything else in the design and structure should follow from this. A developer who knows the goal builds differently from one who has only been told the aesthetic.
2. Who the Site Is For
A one-paragraph description of your typical customer is enough when briefing a web developer: are they comparing you on price, doing research before calling, or buying on impulse? This shapes tone, structure, and what appears above the fold on every page.
3. Examples — Good and Bad
Send three websites you like (from your own industry or not) and say specifically what you like about each — the layout, the way they present pricing, the photography style, whatever it is. Then send one or two you do not like, and explain why. “I like the clean layout of Site A but not the dark colour scheme” is worth more than any amount of abstract description. This is the most useful thing you can put in a brief and the thing most people leave out.
4. What Content You Already Have
Do you have existing text, photos, and logos ready to use, or does that need to be created as part of the project? This single question affects timelines and cost more than almost anything else. When briefing a web developer, be specific — “we have a logo in vector format and about 200 words per service, but no photos” is infinitely more useful than “we can supply content”.
5. Must-Haves vs Nice-to-Haves
Booking systems, multi-language support, an online shop, integrations with other software — list anything essential separately from things that would be nice but are not deal-breakers. This lets a developer scope accurately. Must-haves affect cost and timeline significantly; nice-to-haves can be added in a later phase.
6. Budget Range
This is the question people most often leave out of a brief, usually out of worry that the number will be used against them. In practice, knowing the budget does the opposite — it lets a developer tell you immediately whether your expectations and budget are aligned, rather than discovering the mismatch three weeks into a conversation. A range is fine; an exact figure is not needed. Any developer worth hiring will treat your budget as a scope parameter, not a ceiling to aim for.
7. Timeline
Is there a launch event, a busy season, or a deadline this needs to hit? If there is no hard deadline, say so — that also changes how a project is scheduled, and being honest about flexibility often gets you a faster build date than insisting on urgency that does not exist.
How to Brief a Web Developer: A Free Template
Here is the briefing template I recommend to every client before we start a project. Fill this in and you will get better quotes from every developer you approach:
- Goal: What do you need the website to do? (specific action, e.g. “generate phone enquiries for our plumbing service”)
- Audience: Who is your typical customer in one paragraph?
- Examples: Three sites you like, and specifically what you like about each. One or two you do not like, and why.
- Content: What do you have ready? What needs to be created?
- Must-haves: Features without which the project cannot launch.
- Nice-to-haves: Features that would be useful but are not essential for launch.
- Budget range: A realistic range you are working within.
- Timeline: Any hard deadline, or if flexible, your preferred launch window.
Seven short answers. Any developer worth hiring can produce an accurate fixed-price quote from this brief alone.
What to Leave Out of Your Brief
When briefing a web developer, you do not need to specify fonts, exact colour codes, or technical platforms unless you have a specific reason to. Those are decisions a good developer or designer should be proposing back to you based on everything above. Over-specifying the “how” before the “what” and “why” are clear often locks in poor decisions early. For broader guidance on writing effective project briefs, the Nielsen Norman Group’s guidance on project RFPs is a useful reference even for small projects.
Common Mistakes When Briefing a Web Developer
The most common brief mistake is describing what you want the site to look like instead of what you want it to do. The second is omitting the budget and then being surprised when quotes come in too high or too low for what you expected. The third is not having a clear list of must-have features, which leads to scope creep mid-project as things are added that should have been scoped from the start. You can read more about how we handle projects from brief to launch on our about page, and see examples of the work in our portfolio.
Have a project in mind? Send us even a rough brief and we will come back with a clear, fixed-price quote →
