Send three web agencies a one-line request like "we need a new website, modern and fast, can you quote?" and you'll get three quotes that are thousands of dollars apart. None of them will be wrong. Each agency simply guessed at a different project. A project brief removes most of that guessing. It tells developers what you're trying to achieve, what has to be built, and what constraints they're working within, so they can quote the project you actually have.
The good news is that a useful brief doesn't need to be long or technical. It needs to be specific. This guide walks through every section of a brief developers will love, gives you a copy-paste template, shows good and vague examples side by side, and explains what happens after you hit send.
Key takeaways
- A clear brief leads to more accurate quotes, fewer change requests and a faster start, because developers can see the real scope.
- Lead with business goals and success metrics, not features. Features only make sense next to the problems they solve.
- Always include a budget range and a realistic deadline. They shape the solution as much as the feature list does.
- Be explicit about content ownership, integrations and hosting. These are the most common sources of surprise costs.
- You don't need perfect answers. "We don't know yet" is a useful answer, because it tells the team what to explore during discovery.
Why a project brief matters
A brief is a short document describing your project's goals, audience, scope, constraints, budget and timeline. It isn't a contract or a technical specification. It's the starting point for a conversation, and that's exactly why it has so much influence on how the project goes.
More accurate quotes
Developers estimate by breaking a project into pieces: templates, features, integrations, content work and testing. Every unknown piece gets covered by an assumption or a risk buffer. A vague brief produces either a padded quote, to cover the unknowns, or a low quote that grows later. A clear brief gives you a number you can plan around.
Fewer change requests
Most mid-project change requests aren't new ideas. They're requirements that existed from the start but were never written down: "Of course the blog needs categories." "We always assumed it would connect to our CRM." Writing these down up front moves them into the quote, where they cost less, instead of into change orders, where they cost more and delay launch.
Faster alignment inside your own team
Writing a brief forces internal decisions early. Who approves the design? Is the online store part of phase one? Answering these before talking to an agency saves weeks of back-and-forth.
The sections of a great web project brief
Here's what each section should cover and why developers care about it. Not every project needs every section in depth, but skipping one entirely usually means someone will have to guess.
1. Company overview and business goals
Explain briefly who you are and what you sell, then describe what the project must achieve for the business. "Generate 30% more qualified demo requests" or "let customers reorder supplies without calling us" is far more useful than "refresh our online presence." Goals help the team prioritize when time or budget runs short.
2. Target audience
Describe your main user groups: who they are, what they come to do, and what devices they use. A B2B procurement manager on a desktop and a consumer browsing on a phone need very different experiences. If you have analytics data, share the top-level numbers, such as the mobile vs desktop split and top landing pages.
3. Scope and features
List the functionality you need, ideally split into "must have," "should have" and "nice to have." Describe what each feature does from the user's point of view ("visitors can filter case studies by industry"), not how to build it. Developers will suggest the right technical approach.
4. Page list or sitemap
A simple outline of pages, or a sitemap, is one of the most valuable things you can provide. On WordPress projects, the number of unique templates drives cost far more than the total page count. Twenty service pages that share one layout cost much less than twenty bespoke layouts. Mark which pages share a structure.
5. Content ownership
State who writes the copy, who supplies photos and video, and who moves content from an old site. Content is one of the most common causes of launch delays. If you need copywriting, photography or migration help, say so, so it's included in the plan.
6. Design references and brand assets
List two to five websites you like and, importantly, what you like about each (navigation, typography, product pages, tone). Mention sites you dislike too. Say whether you have brand guidelines, a logo in vector format and a color palette, or whether design work starts from scratch. For complex products, consider a prototyping phase. Our article on UX prototyping before development explains when it pays off.
7. Integrations
List every external system the site must talk to: CRM, email marketing, payment gateways, ERP or inventory, booking tools, membership systems, single sign-on, shipping providers. For each, note whether it's one-way (sending form leads) or two-way (syncing stock levels), and whether the system has a documented API. Integrations are where estimates most often go wrong, so detail here pays off.
8. Technical constraints and hosting
Tell developers what already exists and what's fixed. Do you have a current platform, a hosting provider you must stay with, a required CMS, security or compliance requirements, or an internal IT team that has to approve the setup? If you have no preference, say so. The team can then recommend an appropriate stack, such as WordPress for content-driven sites or a custom web application for complex logic.
9. SEO and analytics
If the site already ranks in search, URL changes and redirects need careful planning, so mention your most important pages and any known traffic. Note which analytics, tag management or consent tools you use, and any conversion events you need to track. Google's SEO Starter Guide is a good primer if you're unsure what to ask for.
10. Accessibility
State your accessibility target. For most business sites, that's conformance with WCAG 2.2 at level AA. Accessibility affects design, content and code, so it's much cheaper to plan from the start than to retrofit. If you sell to public-sector clients or operate in regulated markets, mention any legal requirements you're aware of.
11. Timeline and deadline
Give your ideal launch date and explain whether it's hard (a trade show, a product launch, a contract ending) or flexible. Also note internal availability. If your team needs a week to review designs, or key people are away in August, the schedule should reflect that.
12. Budget range
This is the section people most often leave out, and it's the one that saves the most time. A budget range doesn't weaken your negotiating position. It lets the team propose the best solution for that amount instead of guessing between a lean build and a premium one. The EveryCode project planner uses these brackets (USD):
- Up to $3,000
- $3,000–$10,000
- $10,000–$25,000
- $25,000–$50,000
- $50,000+
For reference points, our fixed-price packages start from $1,200 for a landing page and $3,500 for a WordPress business website. Our guide to WordPress website development cost explains what moves a project between brackets.
13. Decision makers
Name the project owner (the day-to-day contact) and anyone who approves design, content or budget. Unclear approval chains are a major cause of delays. A design approved by marketing and then reopened by the CEO two weeks later can cost more than any technical problem.
14. Success metrics
Define how you'll judge the project six months after launch. Examples include conversion rate on the quote form, online revenue, support tickets per order, page load times, or the time it takes your team to publish a page. Metrics turn subjective feedback into productive decisions.
Free web project brief template (copy and paste)
Copy this template into a document, fill in what you can, and save it as a PDF or Word file. One to three pages is plenty for most projects.
- Project name and contact: Your company, website (if any), project owner's name and email.
- About us: Two or three sentences on what your business does and who it serves.
- Business goals: The top three outcomes this project must deliver, in measurable terms where possible.
- Target audience: Main user groups, what each needs to do on the site, and their typical devices.
- Project type: New website, redesign, online store, web application, plugin or other.
- Scope and features: Must have / should have / nice to have, described from the user's point of view.
- Page list or sitemap: All planned pages, with pages that share a layout marked.
- Content: Who writes copy, who supplies images, whether content must be migrated, and roughly how much.
- Design: Brand assets available, two to five reference sites with what you like about each, and sites or styles to avoid.
- Integrations: Each third-party system, its purpose, the direction of data flow and whether an API is available.
- Technical constraints and hosting: Current platform, hosting, required technologies, security or compliance needs.
- SEO and analytics: Important existing pages and rankings, analytics tools, conversion events to track.
- Accessibility: Target standard (for example, WCAG 2.2 AA) and any legal requirements.
- Timeline: Ideal launch date, whether it's hard or flexible, and why. Note internal review availability.
- Budget range: Up to $3,000 / $3,000–$10,000 / $10,000–$25,000 / $25,000–$50,000 / $50,000+.
- Decision makers: Project owner and approvers for design, content and budget.
- Success metrics: How you'll measure success three to six months after launch.
- After launch: Who will maintain the site, and whether you want ongoing support, updates and backups.
- Open questions: Anything you're unsure about and want the development team's advice on.
Good vs vague: example brief statements
The difference between a useful brief and a vague one is rarely length. It's specificity. Here's how common statements compare:
| Section | Vague | Good |
|---|---|---|
| Goals | "A modern website that represents our brand." | "Double monthly quote requests from organic traffic and cut sales calls about pricing by publishing clear packages." |
| Audience | "Everyone interested in our services." | "Operations managers at mid-size logistics firms, mostly on desktop. Secondary: job applicants on mobile." |
| Features | "A shop and a blog." | "WooCommerce store with about 120 products, 3 variations each, Stripe and PayPal, local pickup option, blog with categories." |
| Integrations | "Connect to our systems." | "Send form leads to HubSpot (one-way), sync stock levels hourly with our inventory software via its REST API." |
| Content | "We'll sort out content." | "We write all copy. We need help migrating 85 blog posts from the old site and sourcing stock photos." |
| Timeline | "ASAP." | "Launch by March 15 for a trade show (hard deadline). Design reviews within 3 business days." |
| Budget | "Competitive pricing please." | "$10,000–$25,000, with flexibility for phase two features." |
Common brief-writing mistakes
- Prescribing solutions instead of describing problems. "We need a chatbot" might be right, but "customers can't find delivery information" lets developers suggest a cheaper, better fix.
- Hiding the budget. Without a range, you'll receive proposals designed for someone else's budget and lose a round of revisions.
- Treating every feature as essential. If everything is a must-have, nothing can be phased. Prioritizing lets you launch sooner and add features later.
- Forgetting the people who'll use the admin. Editors, store managers and support staff are users too. Describe their daily tasks.
- Ignoring life after launch. Updates, security, backups and performance monitoring need an owner. If you need ongoing help, mention it so it can be planned, for example through a WordPress maintenance and security care plan.
- Writing a 40-page document nobody reads. Long requirement lists without priorities are almost as hard to quote as no brief at all. Be concise and attach detail as appendices.
What happens after you send your brief
At EveryCode, a brief is the start of a structured but lightweight process. Here's what to expect.
Step 1: Discovery
You submit your brief through the project planner. The form accepts uploads in PDF, DOC, DOCX, PNG, JPG, ZIP, RAR, XLS and XLSX formats, so you can attach the brief itself plus spreadsheets, sketches or brand files. We review everything and follow up with clarifying questions by email or a short video call. Gaps get filled here, and open questions get turned into options with trade-offs.
Step 2: Free quote
Based on discovery, you receive a free quote with the proposed scope, approach, timeline and price. For larger or less defined projects, we may suggest starting with a prototyping or planning phase so the main build can be quoted precisely.
Step 3: Approval and production
Once you approve the quote and pay to send it to production, development begins, with regular updates by email, Slack or video calls. Delivered work comes with a 14-day money-back guarantee and a two-week post-launch warranty for bug fixes, with optional ongoing maintenance afterward. Answers to common process questions are collected on our FAQ page.
Frequently asked questions
How long should a website project brief be?
For most websites, one to three pages is enough. Focus on goals, scope, constraints, budget and timeline, and attach detailed material such as product spreadsheets or existing designs as separate files rather than making the brief itself longer.
Should I include my budget in the brief?
Yes. A budget range lets developers propose the best solution for what you can spend, instead of guessing. It doesn't weaken your negotiating position. It prevents proposals that are far above or below what you planned.
What if I don't know the technical details?
That's normal. Describe what you need in business terms, list the systems you already use, and mark anything you're unsure about as an open question. Technical choices are the development team's job, and discovery is where they get clarified.
What's the difference between a project brief and a technical specification?
A brief describes goals, audience, scope, constraints, budget and timeline, mostly in business language. A technical specification describes exactly how the system will be built, such as data models, APIs and architecture. Developers usually write the specification based on your brief and discovery.
What file formats can I upload to the EveryCode project planner?
The project planner accepts PDF, DOC, DOCX, PNG, JPG, ZIP, RAR, XLS and XLSX files, so you can send a written brief, spreadsheets, sketches or a zipped folder of brand assets.
Will I get a quote without a complete brief?
Yes. Send what you have, even a few paragraphs. We'll ask clarifying questions during discovery and then prepare a free quote. A more complete brief just means fewer questions and a faster, more precise estimate.
Ready to put your project on paper? Copy the template above, fill in what you know, and upload it through the EveryCode project planner for a free quote after discovery. Want a ballpark first? Our pricing page lists fixed-price packages for landing pages, WordPress websites, WooCommerce stores and SaaS MVPs.
