How to Write a Clear Web Development Project Brief (Before You Hire)

What a web development project brief actually is

A brief is a decision document, not a wish list. A wish list says “we want everything, make it amazing.” A decision document says “here’s what we’re trying to achieve, here are our limits, and here’s what we’ll trade off if we have to.” The first invites scope creep. The second gives the people quoting your project a real shot at being right about price and timing.

Think of it as the thing everyone returns to when a question comes up six weeks in. Whose call is this? What did we agree the homepage needed to do? Without that anchor, every small decision turns into a fresh negotiation.

Why a vague brief costs you real money

Send a one-liner and you’ll get one of two responses back. A padded quote, where the agency assumes the worst and prices for it. Or a lowball quote that balloons the moment reality hits. Neither helps you.

There’s a second cost that’s easy to miss. When three agencies quote off a vague brief, you get three answers built on three different sets of assumptions. One assumed five pages, one assumed fifteen, one assumed you’d write all the content yourself. You can’t line them up against each other. You’re not choosing between agencies at that point. You’re choosing between guesses.

A clear brief fixes both problems at once. Same information in, comparable numbers out.

What to put in your web development project brief

You don’t need a forty-page PDF. Two to four pages covers most projects. Here’s what earns its place.

1. Who you are and why this project exists

Start with a sentence or two on the business: what you sell and who buys it. Then the part people skip. Why now? A refresh because the old site looks dated is a different project from a rebuild because checkout keeps failing. Say which one you’re doing.

2. The goal, not the feature list

“We want a new website” isn’t a goal. “We want to cut the number of calls asking for our opening hours” is. So is “we want to take bookings online instead of over email.” Goals like these tell a good team what the site has to do, which is far more useful than a list of pages. And if part of what you’re after is showing up in search, flag it now, so it gets built into the site’s structure instead of bolted on after launch.

3. Who the site is for

One or two sentences on your main visitor will do. A 55-year-old facilities manager comparing suppliers behaves nothing like a 22-year-old buying trainers on their phone. The first wants spec sheets and a phone number. The second wants three taps to checkout. Your developer designs differently for each, but only if you tell them which one matters.

4. Scope: must-haves and nice-to-haves

This is the section that saves you the most money, so give it room. List the pages and features you want. Then sort them into two buckets: must-have and nice-to-have. Online booking? Must-have. Blog and live chat? Nice-to-have. When the quote comes back higher than you hoped, you’ll already know what to trim without another week of emails. And if your project includes an online store, say so up front. An ecommerce build carries payment, inventory, security, and compliance work that a simple brochure site doesn’t.

5. Design direction, including what you hate

Most people describe what they want as “clean and modern.” Everyone says that, and it tells a designer almost nothing. Far better: link two or three sites you like and say what you like about each. Then do the rarer, more useful thing and link a site you dislike, with a reason. “Too busy, too many pop-ups” lands harder than a paragraph of adjectives. If you have brand colors, a logo, or fonts, attach them.

6. Who’s writing the content

Here’s a gap that quietly wrecks timelines. The agency assumes you’re supplying the words and photos. You assume the agency is writing them. Three weeks in, the build stalls because nobody has produced the About page copy. Decide this up front. If you need words written, say so and budget for it. That’s a content line item, not a freebie.

7. Technical needs and anything it has to connect to

You don’t need to know how any of this works under the hood. You just need to flag it. Does the site have to talk to your booking software, your CRM, your email tool, your accounting system? Are you keeping your current host or moving? Do you still have the logins for your existing site? A single sentence on each is plenty. The team will ask the follow-up questions.

8. A timeline with a reason behind it

“ASAP” is the least useful word you can put in a brief. It tells an agency nothing except that you might be hard to please. Give a real date, and where you can, the reason: “We’d like to launch before our trade show on 15 October.” Now a team can tell you honestly whether that’s realistic. For reference, across the 80+ projects we’ve delivered, a standard business website usually runs two to four weeks, while an ecommerce store or custom build tends to take six to twelve. We broke down the whole thing in our guide on how long it takes to build a website.

9. Your budget, with an actual number

This is the one people resist hardest, so let me be blunt. Holding back your budget doesn’t win you a better price. It wins you a guess, and guesses tend to be wrong in the direction that wastes your time. A range is fine. “$5,000 to $8,000” lets a good agency tell you straight away whether your must-haves fit inside it, and if they don’t, where to cut. Keeping it a secret just buys you three rounds of quotes before anyone discovers you were never in the same ballpark.

10. Who we talk to, and who decides

Name your point of contact. Then, separately, name the decision-maker. They’re often one and the same, and sometimes they’re not. The projects that drag are almost always the ones where five stakeholders each hold a veto and none of them agree. Sort that out before the work starts, not during the fourth round of homepage revisions.

Got most of this written down already? Good. That’s the hard part done. Talk to us and we’ll tell you honestly what’s realistic for your budget and timeline.

Common mistakes that quietly sink a brief

A few patterns we see over and over:

• Describing the solution instead of the problem. “We need a homepage carousel” often really means “we have too much to say and can’t decide what to lead with.” Give the team the problem and let them solve it.
• Leaving out the existing site. If you have one, link it. Say what’s working and what isn’t, and point to anything useful in your analytics. A rebuild always starts from somewhere.
• No budget and no timeline. Covered above, but worth repeating, because it’s the single most common reason a quote comes back useless.
• Writing it by committee with no editor. Ten contributors means ten priorities and no clear ask. One person should own the document.

A quick before-and-after

Here’s the same requirement written two ways.

Vague: “We want a modern, professional website that really stands out and works well on mobile.”

Clear: “We want a clean, minimal site, similar in feel to [competitor A] but a little warmer. We dislike heavy stock photography and auto-playing video. Five core pages, a blog, and a contact form that emails our sales inbox. It has to work well on phones, since most of our traffic is mobile. Brand colors are navy and warm grey; logo attached.”

The second one takes five extra minutes to write. It saves you a week of back-and-forth and gets you a quote you can actually trust.

How your brief shapes the proposals you get back

A good agency reads your brief and comes back with questions before it comes back with a number. Treat that as a green flag. It means they’re thinking about your goal, not just counting pages. A team that fires a quote back within the hour either skimmed it or is guessing.

The clearer your brief, the more your proposals start to behave like real comparisons. Same scope, same deliverables, prices you can weigh against each other. Get a quote from a shortlist of two or three teams and you’ll see how differently they each read the same document. That’s the point where you’re genuinely choosing a web development partner, rather than betting on whoever sounded most confident on the call.

Write the brief first. It’s the cheapest insurance you’ll buy on the whole project. When you’re ready, start your project with a team that’s worked with 100+ clients over eight years.