Most businesses approach a web project backwards. They contact developers, describe their situation vaguely, get quotes that vary wildly, feel confused about why, and either pick the cheapest option or stall out entirely. The root cause of almost all of that is a weak brief.
A good brief doesn’t just help developers understand your project — it helps you understand it too. And when everyone is working from the same clear picture, quotes get more accurate, timelines get more realistic, and the finished product is far more likely to be what you actually wanted.
Here’s what to put in one.
Start With Your Business, Not Your Website
The first thing a developer needs to understand isn’t what you want the site to look like — it’s what your business does, who your customers are, and what success looks like. A website is a means to an end. Describe the end first.
Include: what your business does in plain language, who your target customers are, what you want visitors to do when they land on your site, and how your current site (if you have one) is falling short. These four things give a developer more useful context than three paragraphs about wanting something “modern and clean.”
Be Specific About What the Site Needs to Do
This is where most briefs fall apart. “I need a website” tells a developer almost nothing. “I need a seven-page WordPress site with a contact form, a portfolio gallery, and a booking system that integrates with Calendly” tells them quite a lot.
Go through your requirements feature by feature. Do you need e-commerce? A blog? A membership area? Multiple languages? Integration with your CRM or email platform? Custom calculators or configurators? Each of these affects the scope, the timeline, and the cost. The more specifically you can describe what the site needs to do, the more accurate the quote you’ll receive.
Don’t worry about knowing the technical solution — that’s the developer’s job. Just describe the problem or outcome you need: “Customers need to be able to book appointments and receive automated confirmation emails” is enough. You don’t need to specify which booking plugin.
Describe What You Have and What You’re Keeping
If you have an existing site, say so — and be honest about what’s wrong with it. If you’re keeping your current domain, hosting, or any existing content, say that too. If you have brand guidelines, a logo, or approved copy, that changes what the developer needs to produce. If you’re starting from scratch with nothing, that also needs to be clear.
Developers price based on assumptions. If they assume you’re providing ready-to-use copy and images and you’re actually expecting them to source or create those, the quote will be wrong — and not in a pleasant direction when the conversation happens later.
Share Examples — But Be Clear About What You Like
“Something like this” is one of the most useful things you can include in a brief, as long as you explain what you mean by it. Sharing three or four websites you admire and noting what specifically appeals to you — the layout, the color palette, the photography style, the navigation structure — gives a designer far more to work with than describing your aesthetic in words.
It’s equally useful to share examples of what you don’t want. If you have a strong reaction against a certain style, say so. It avoids entire rounds of revision.
State Your Budget Range Honestly
This is the part people are most reluctant to include, usually out of fear that naming a number will anchor the quote too high. In practice, the opposite is true. Without a budget range, developers either assume a figure and quote for it, or they scope out everything possible and give you a number that makes no sense for your situation.
Giving a range — even a wide one — lets a developer tell you honestly whether your expectations align with your budget, and if they don’t, what tradeoffs are available. “We have $8,000–$12,000 for this project” is actionable information. “We don’t have a set budget” usually means several back-and-forth exchanges before you get to the same conversation anyway.
Include Your Timeline
Do you need the site live by a specific date? Is there a product launch, event, or campaign tied to the launch? Say so upfront. Rushed timelines cost more and occasionally aren’t feasible at all — better to know that at the quoting stage than three weeks before your deadline.
If you don’t have a hard deadline, say that too. Flexible timelines sometimes allow for better pricing and give the developer room to do the job properly rather than cutting corners to hit an arbitrary date.
Describe What Happens After Launch
Will you manage the site yourself? Do you need training? Are you expecting ongoing support from the developer? Do you already have hosting, or do you need the developer to recommend and set that up?
Post-launch support and maintenance is where a lot of client-developer relationships either work well or fall apart. Clarifying expectations in the brief means both parties go into the project knowing what the long-term arrangement looks like.
What a Good Brief Gets You
A clear, complete brief does several things at once. It signals to developers that you’re a serious client who has thought through the project — which tends to attract more serious responses. It gives them enough information to quote accurately rather than padding for uncertainty. And it gives you a document you can use to compare quotes apples-to-apples, because everyone is responding to the same set of requirements.
It also forces a useful exercise for you: if you can’t describe clearly what you want the site to do and why, that’s a sign there’s more thinking to do before any developer conversation starts.
Ready to Talk Through Your Project?
At Interactive Design Group, we’re happy to work through a brief with you from scratch. If you have a project in mind but aren’t sure how to scope it, get in touch — we’ll ask the right questions and help you figure out exactly what you need before any numbers are discussed.