Getting a web project off to a good start means building a solid project brief, not a feature list. A project brief is an honest description of where you are, where you want to go, and what is stopping you. Most web projects that go wrong have one thing in common: the initial document was incomplete. Not because clients lack good intentions, but because nobody told them what an agency actually needs to start working.
If you are preparing a web project, whether it is your first or your budget ran over on the last one, this guide is for you. It takes the agency's perspective: what they are really trying to understand when they receive your document, and what is almost always missing.
Why most project documents do not work
Most documents agencies receive look like feature lists: a contact form, a product page, a blog section, a CRM integration. That is not a problem in itself. It is the problem: a feature list does not describe what you are trying to solve. The agency does not know why those features were chosen, what they are supposed to produce, or what happens if one of them turns out to be the wrong answer.
A good project brief starts with the problem, not the solution. That one shift changes everything.
What an agency actually needs to know
A well-built project brief answers six core questions.
1. What is the context?
Who are you? What does your organization do, and who are your users? How does your current website fit into your day-to-day operations? This feels obvious from your side, but an agency that does not know your industry has to reconstruct this from scratch, often with gaps.
2. What is the problem you are trying to solve?
Not "we want a new website." But: our conversion rate has been declining for two years, we are losing leads on the contact form, our current site cannot be updated without a developer, our team spends ten hours a week managing content manually. That kind of framing gives the agency something to work with.
3. What is the functional scope?
The functional scope defines what your future site needs to be able to do, without getting into individual features. For example: "the site needs to allow a non-technical team to manage content independently, support English and French, and integrate with our CRM." This level of description guides architectural decisions without locking in a solution. The detailed feature list comes later, built together with the agency.
4. What are your objectives and success criteria?
"A better website" cannot be measured. "Reduce content update time by 80%" or "increase inbound requests by 20% within six months" gives the agency clear direction and gives you a concrete way to know, at the end, whether the project delivered.
5. What are your real constraints?
Budget, timeline, available internal team, existing systems the site needs to connect with (CRM, ERP, management tools), non-negotiable technology choices. Do not hide these out of fear of anchoring the agency's proposal. The opposite is true: sharing them allows the agency to propose something realistic.
6. Who makes decisions?
A project without an identified decision-maker stalls at every stage. Your document should specify who signs off on deliverables, who has final say on visual and functional choices, and how feedback is collected on your side.
Quick reference: the six questions your project brief must answer:
- Context: who you are, what you do, who your users are
- Problem: what is not working today, and why
- Functional scope: what the site needs to cover, in broad terms
- Objectives: measurable goals and success criteria
- Constraints: budget, timeline, existing systems, technology choices
- Decision-making: who validates, who has final say
The most common mistakes
Hiding the budget. Many clients hesitate to share their budget, worried the agency will simply match it. Understandable, but counterproductive. Without a number, the agency cannot calibrate its proposal. It may come back with something oversized, or something too thin. An honest range saves everyone time.
Sending a specification document instead of a project brief. A detailed spec tries to answer every question before the right questions have been asked. That has its place, but not at the start. The discovery phase is the first stage of a project, where the agency and you define scope and approach together before a single line of code is written. That phase should come before the spec, not after. Your project brief needs to be readable in twenty minutes.
Leaving out internal stakeholders. Someone on your side will use this website: a marketing team, a content editor, a system administrator. If those people are not involved in preparing the project, their constraints will surface during development as change requests. Better to identify them early.
Mistaking personal taste for a project objective. "I want something modern and clean" describes an aesthetic preference, not an objective. Design decisions should be driven by user needs and project goals. A site built for institutional buyers operates under different rules than a consumer-facing one.
What a good project brief actually produces
When your brief is well-built, the first meeting with the agency changes entirely. Instead of spending an hour explaining what your company does, you go straight to the real questions: which technical approach, how the project will be organized, what risks to anticipate. A good agency will build on your document with its own questions, particularly about what has not worked in the past, information that rarely makes it into written documents but is often decisive.
An agency that understands your problem can offer real trade-offs. Budget too tight to do everything: they tell you what to cut and why. Timeline under pressure: they tell you honestly what holds and what does not. Those conversations only happen when the agency understood your situation before walking into the room.
That is the real value of a good project brief: an agency that can act as an advisor rather than just an executor.
Frequently asked questions
How long does it take to prepare a project brief?
A well-built project brief does not need to be long. Five to ten pages is enough if the key information is there. What matters is having answered the six questions described in this article before you send it.
Should I include my budget in a project brief?
Yes. Sharing an honest budget range helps the agency calibrate its proposal and avoids unnecessary back-and-forth. A serious agency has no interest in mechanically matching your ceiling: its reputation depends on what it delivers, not what it invoices. If your budget is not enough for what you are asking, they will tell you. If it works, they will propose what actually fits your situation.
What is the difference between a project brief and a technical specification?
A project brief is the starting document. It describes the problem, the objectives, the constraints, and the context. A technical specification is a more detailed reference document that defines individual features and technical requirements. It is usually co-built with the agency after the discovery phase, based on the initial brief. If the discovery phase also surfaces a need for additional technical capacity, our guide to what makes staff augmentation work covers when that model is the right fit.
When should I send my project brief?
Ideally with your first outreach, before a meeting is even scheduled. A brief sent in advance allows the agency to prepare, ask better questions, and make the first meeting productive rather than a basic information-gathering session.
How do I choose between agencies using the same document?
Send it to two or three agencies and pay attention to the quality of the questions they send back. A good agency does not rush straight to a proposal. It tries to understand the problem first. The questions asked before the proposal are often more revealing than the proposal itself.
A well-prepared project is a project half done
Most budget overruns, missed deadlines, and disappointing results share a common origin: a misunderstanding at the start that was never corrected. A solid project brief does not guarantee a perfect project, but it gives everyone the same foundation to work from.
If you are preparing a web project and want an outside perspective on your approach, our consulting and advisory service is built for this stage. And if you are ready to move into development, get in touch.