How to Write a Web Development Brief That Gets Results

Last year, a Calgary accounting firm sent us a two-sentence email: "We need a new website. What would that cost?" We asked what was wrong with their current site. They said it was "outdated." We asked what they wanted the new one to do. They said they wanted it to "look modern." That was the entire brief.

We quoted them a discovery session instead. Because without knowing their goals, their audience, their content situation, their technical requirements, or their budget range, any number we gave them would have been fiction. And fiction, in web development, turns into change orders.

This is a pattern we've watched repeat for 25 years. A business wants a website. They reach out to a developer or agency. The developer asks for a brief. The business either doesn't know what that means, writes something too vague to act on, or overwrites it with 30 pages of feature requests pulled from competitor sites they admire. The project starts fuzzy. It stays fuzzy. And then everyone wonders why the result doesn't match expectations.

PMI's research has consistently found that poor requirements are the single largest contributor to project failure, responsible for roughly 39% of failed projects across the software industry. Web projects aren't exempt. If anything, they're worse, because the barrier to starting one is so low that people skip the planning entirely.

A web development brief keeps your project on track, your budget intact, and your developer pointed at the right target. Here's how to write one that actually works.

Start With the Problem, Not the Solution

Most briefs we receive start with a solution. "We want a WordPress site with a blog, a booking system, and a gallery page." That's a feature list, not a brief. It tells us what you've decided to build but nothing about why.

The single most useful thing you can put in a brief is a clear statement of the business problem your website needs to solve.

Are you losing leads because your site doesn't rank for local searches? Is your current CMS so painful to update that your team just stopped publishing content? Are you getting traffic but nobody fills out the contact form? Did your last developer disappear and now you can't make changes without hiring someone new?

These are different problems. They lead to different solutions. A business that needs better local search visibility might not need a redesign at all. They might need structured data markup and proper technical SEO. A business with a CMS problem might need a platform migration, not a rebuild. The solution depends entirely on the diagnosis.

When we get a brief that says "we want more leads from our website," we can work with that. When we get one that says "we want a React site with a headless CMS and a custom booking API," we have to figure out whether that stack actually fits the problem or whether someone read a blog post and got excited.

Write down what's broken. Write down what you wish your site did that it doesn't. Write down the business outcome you're after. Let the developer figure out how to get there.

What Your Brief Needs to Include

A useful brief doesn't have to be long. Some of the best ones we've received fit on two pages. But it does need to cover specific ground.

Your business and your audience

Who you are, what you sell or offer, and who your customers are. This sounds basic, but we've received briefs for projects worth $15,000+ that never mentioned who the site's visitors would be. A website for a B2B industrial supplier needs a completely different content structure, tone, and user flow than one for a consumer-facing restaurant group. If you serve a specific geographic market, say so. If 60% of your customers find you through Google, that changes the technical priorities.

What's wrong with what you have now

If you have an existing site, tell us what you hate about it. Be specific. "It looks dated" is a start, but "I can't update the homepage without calling my developer, our contact form submissions go to an inbox nobody checks, and we don't show up in Google for anything except our business name" gives us something to work with.

Run your current site through Google's PageSpeed Insights before you write the brief. Include the scores. If your mobile performance score is 28, that tells a developer more about your situation than any paragraph of description could.

Your goals, stated as outcomes

Not "we want a blog" but "we want to publish two articles a month to rank for insurance questions in southern Alberta." Not "we want a modern design" but "we want first-time visitors to understand what we do within five seconds of landing on the homepage." Not "we want e-commerce" but "we want to sell our four workshop packages online and reduce the admin time we currently spend on manual invoicing."

Outcome-based goals give your developer a way to measure whether the project succeeded. Feature-based requests give them a shopping list with no context.

Your content situation

This is the part almost every brief skips, and it's the part that derails more projects than anything else. Content means your text, your images, your videos, your case studies, your team bios, your product descriptions. Someone has to write all of it. Is that you? Is that the developer? Is it a copywriter you'll hire separately?

We have seen projects delayed by two, three, even four months because the client assumed the developer would write the copy and the developer assumed the client would. Get this sorted before the project starts. If you don't have content ready, say so. A good developer will build that into the timeline and recommend a content strategy. A bad one will launch with placeholder text and call it done.

Technology preferences (if you have them)

If you already run WordPress and your team knows how to use it, say that. If you've been told you need to move off Squarespace, say that and say why. If you have no idea what platform is right, say that too. We wrote a full comparison of how different CMS platforms fit different business needs, and your developer should be asking questions about your team's technical comfort before recommending anything.

What matters here is honesty. If nobody on your team has ever logged into a CMS, don't ask for a platform with a learning curve that requires developer training. If your previous developer built your site on a tool nobody else can maintain, mention that so the new developer doesn't repeat the mistake.

Budget range

This is where people get cagey. "We don't want to share our budget because the developer will just spend all of it."

We understand the instinct. But withholding your budget is like walking into a car dealership and refusing to say whether you're shopping for a Honda Civic or a Mercedes S-Class. The salesperson can't help you until they know the category, and neither can a developer.

A $5,000 budget produces a very different website than a $25,000 budget. Both can be good. But the scope, the platform, the design process, and the deliverables are different at every price point. We broke down what each budget range actually gets you, and it's worth reading before you start talking to developers.

You don't have to give an exact number. A range works. "$8,000 to $15,000" tells a developer enough to propose something realistic. "Whatever it costs" is a blank cheque that leads to misaligned expectations on both sides.

Timeline and launch drivers

Do you have a hard deadline tied to a product launch, a trade show, or a regulatory requirement? Or is the timeline flexible? Both answers are fine, but they produce different project plans.

A six-week timeline limits what's possible. A six-month timeline opens up more options but also creates the risk that the project loses momentum and stalls. If you have a real deadline, name it. If you don't, be honest about that too, because a developer will plan differently if they know they have breathing room versus a fixed date.

What to Leave Out

Not everything belongs in a brief. Some of the longest briefs we've received were also the least useful, because they were full of noise that made the signal hard to find.

Skip the competitor analysis that's actually a wish list. "We want our site to look like Apple's but also function like Amazon's checkout and have Airbnb's search filters" doesn't help. If you admire how a specific site handles navigation or presents pricing, say that specifically. But a list of 12 competitor URLs with "we want all of this" attached is a recipe for scope that nobody can deliver on budget.

Skip the technology mandates you don't understand. If someone on your board read that headless CMS architecture is the future and now it's a requirement in your brief, but nobody on your team can explain why, leave it out. Let the developer recommend the technology based on your actual needs. That's literally what you're paying them for.

Skip the pixel-perfect design direction unless you've hired a designer. "We want the hero image to be exactly this size with this font at this colour" in a brief to a developer who hasn't started discovery yet is premature. Share your brand guidelines, your logo files, and a few sites whose visual style you like. That's enough for a developer to start designing with your taste in mind.

And skip the pages-and-features list that has no priorities. Telling a developer you need 47 pages, a booking engine, a members-only portal, a blog, e-commerce, live chat, and an event calendar with no indication of what matters most means everything gets equal weight. Which means when the budget runs tight, nobody knows what to cut. Rank your requirements. Must-have, nice-to-have, and future-phase. That single act of prioritization will save you thousands in avoided scope creep.

A good brief answers two questions clearly: what business problem are we solving, and how will we know when it's solved?

The Mistakes That Cost Real Money

We've worked on hundreds of web projects. The ones that go badly almost always trace back to the brief, or the absence of one.

No brief at all. This is more common than you'd think. The project kicks off based on a phone call and a handshake. Three months in, the developer has built what they understood. The client expected something different. There's no document to reference because none exists. Both sides are right and both sides are frustrated.

The brief that describes a solution the business doesn't need. A nonprofit came to us after spending $22,000 on a custom web application with member login portals, event registration, and a donation processing system. Their actual need? A five-page informational site with a link to their CanadaHelps donation page. The brief had been written by a board member who worked in software and assumed the website needed the same architecture as their enterprise tools. Nobody pushed back.

Scope described in features, not outcomes. When the brief says "build a blog" instead of "we need to publish content that ranks for specific search terms," the developer builds a blog. It might not have proper heading structure. It might not have schema markup. It might not have category taxonomy or internal linking built into the template. It meets the spec. It doesn't meet the need.

Missing content planning. We quoted a project at $12,000. The client approved. Six months later, the project still wasn't launched. The design was done. The development was done. The client hadn't written a single page of content. Every week of delay cost them traffic, leads, and the momentum of their original excitement. The brief never addressed who was responsible for content or when it would be delivered.

These aren't edge cases. PMI data shows that 52% of projects experience scope creep, with an average cost overrun of 27%. For web projects specifically, unclear requirements at the start are the single most common cause. The brief is your insurance policy against that.

What Happens After You Send It

A brief isn't a contract. It's a starting point for conversation.

A good developer will read your brief and come back with questions. Lots of them. That's what you want. If a developer reads your brief and immediately sends a quote with no follow-up questions, they're either guessing at the scope or planning to figure it out as they go. Neither approach ends well. We covered this in our guide to questions you should be asking developers, and the same principle works in reverse. The developers asking you the hardest questions are the ones most likely to deliver the right thing.

Expect a discovery phase. Some developers build this into their quote. Others charge for it separately. Either approach is valid. What matters is that someone spends time understanding your business before they start building. Discovery typically produces a project plan, a sitemap, a content outline, and a technical specification that's far more detailed than your original brief. That document becomes the real scope of work, and it should be something both sides agree to before a single line of code gets written.

Your brief should also name who makes decisions. If four people need to approve the homepage design, say that upfront. If the CEO wants sign-off on every page, that changes the timeline. If the marketing coordinator has final say on content but the IT manager has final say on platform, those are different approval tracks that need to be planned for. Projects stall when approval authority is ambiguous. We've watched three-week review cycles happen because nobody knew whose opinion was final.

One last thing. Ask the developer what they'd add to the brief. Every project is different. Your developer might need information about your existing hosting, your email marketing setup, your analytics configuration, your accessibility requirements, or integrations with tools you already use. A brief is a living document. The best version of it is the one you and your developer build together.

The businesses that write clear briefs get better websites. Not because the brief itself is magic, but because the act of writing it forces you to answer the hard questions before money is on the table instead of after. Do the thinking upfront, and the building goes smoother for everyone.

Sources

1. PMI - Projects Fail Due to Poor Requirements Management -- PMI research on requirements as the primary cause of project failure
2. PMI - Pulse of the Profession 2025 -- Annual project management industry report on success rates and contributing factors
3. Standish Group CHAOS Report -- Long-running research on IT project success and failure rates (31% success rate in 2020 report)
4. Google PageSpeed Insights -- Google's tool for measuring page load performance, referenced as a pre-brief diagnostic
5. Monday.com - Scope Creep in Project Management -- Statistics on scope creep prevalence (52% of projects) and budget overruns
6. Milanote - How to Write a Website Design Brief -- Industry guide on brief structure and best practices
7. Requiment - Why Do Software Development Projects Fail -- Research on requirements gathering as primary failure cause (39% of cases)
8. PMI - Poor Requirements Management as Source of Failed Projects -- PMI paper on the link between requirements clarity and project outcomes