Why the brief is the thing that decides your quote
Send the same request to five studios and you will get five wildly different numbers back. People usually read that as the market being opaque. Most of the time it is simpler: the request did not say enough to price, so each studio guessed, and they guessed differently. The spread you are looking at is the size of the ambiguity, not the size of the disagreement.
A supplier who cannot see the edges of a job has two options. Quote low and hope, which ends in change requests and a bad relationship, or pad the number to cover what might be hiding, which is what most experienced ones do. Either way you pay for the uncertainty. A brief is how you stop paying for it.
The point of writing it down is not the document. It is that several of the questions below are ones you have not answered yet, and finding that out before the work starts costs an afternoon. Finding out halfway through costs the work already done.
The nine questions, and what a good answer looks like
This is the structure we use on real engagements. Work through it in order, because the later answers depend on the earlier ones.
| Section | What a useful answer contains |
|---|---|
| The business | What you sell, to whom, and how the money actually arrives. Two or three sentences. |
| Who it is for | The specific person visiting, and what they came to do. Not a demographic bracket. |
| The problem | What is wrong now. "The site is old" is a symptom; say what it costs you. |
| What success looks like | Something checkable months later that is not "it looks better". |
| Scope | The pages, features and systems in the job. |
| Explicitly out of scope | The things a reasonable person might assume are included and are not. |
| Constraints | Anything fixed: a launch date, a system to integrate with, a brand rule. |
| Who decides | One named person with authority to approve. |
| What you owe the supplier | Content, logins, access, approvals, and by when. |
The four sections almost every brief leaves out
Most briefs cover the business, the audience, the problem and the scope. Those are the easy ones, and on their own they are not enough to price anything. The four below are what separate a brief that produces a firm quote from one that produces a range.
- Explicitly out of scope. This is the single highest-value paragraph in the document and the one people find rudest to write. It is not rude. Naming what is not included is what makes "included" mean something, and it protects you as much as the supplier, because it forces the assumptions into the open while you can still change them.
- Constraints. Every fixed thing is a cost. A hard launch date, an existing booking system that has to keep working, a parent brand's rules, a language requirement. A supplier who learns about the integration in week three prices it as an emergency.
- Who decides. One person with the authority to say yes. Feedback from several people is useful and normal. A decision from several people is the most reliable cause of delay in the industry, and it is a structural problem rather than a personality one.
- What you owe the supplier, and by when. Projects stall on client-side content more than on anything technical. If the copy for eleven pages is coming from you, that is a dependency with a date on it, and it belongs in the brief rather than in a chase email in week six.
If you write only these four and nothing else, you will still get better quotes than most briefs produce.
Writing the success criteria so they survive the project
This section is where briefs go soft. "A modern site that reflects the brand" cannot be checked, cannot be disagreed with, and cannot be failed. That sounds harmless and it is not: it means at the end you will judge the work on how it felt, which favours whoever is most persuasive in the room rather than whichever outcome you actually wanted.
A criterion is useful if you can tell, months later, whether it happened. Some are numbers and some are not, and the non-numeric ones are often the more honest.
- Our team can publish a new page without contacting the developer.
- Enquiries include the information we need, so we stop the back-and-forth before a first call.
- The three products we actually sell are reachable within one click of the home page.
- We can change a price without raising a support ticket.
Write these before you see any designs. Written afterwards, they will describe what you were shown rather than what you needed, and by then the point of having them has gone.
Sending it, and what to expect back
Send the same brief to everyone you are asking, unchanged. It is the only way the numbers you get back are comparable, and the differences that remain are then real differences in approach rather than in what each one imagined you meant.
Judge the replies on the questions as much as the number. A supplier who reads a brief properly comes back with things you left out, and that is the most reliable signal available to you before any work starts. One who quotes immediately without asking anything has either done this exact job many times or has not read it.
- Expect questions about the constraints. Integrations are where estimates go wrong, and a careful supplier probes them first.
- Expect the out-of-scope list to be extended. That is the process working, not the supplier retreating.
- Expect a range rather than a figure if your brief left something genuinely open. A firm number over an open question is not confidence, it is a guess with a decimal point.
- Be suspicious of a quote that matches your budget exactly, particularly if you mentioned the budget.
There is no version of this that replaces a conversation. A brief makes the conversation short and specific instead of exploratory, which is worth more than it sounds when you are having it five times with five suppliers.
What this does not cover
- This is the structure we use, not a standard. Other studios ask for different things and a good supplier will want more than this covers.
- It is written for websites and web applications. A brief for a brand identity, a campaign or a piece of hardware needs different sections, and several of these would not apply.
- It says nothing about what a project should cost or how long it should take, deliberately. Those depend on the answers you write, which is the entire point of writing them first.
- It is not a contract and creates no obligation on anybody. A confirmed brief is a shared understanding; the terms are a separate document, and we are not lawyers.
- The claim that vague briefs cause quote spread is our own experience of quoting, not a measured study. We have not run a controlled comparison and could not honestly publish a number for it.
Sources
- What Scene project brief template, documents/transactional/project-brief. The public version of a template issued to clients at the start of an engagement, defined in lib/documents/defs/engagement.ts. Read in full before publishing; every client-specific value in the original is a placeholder rather than a value. Run: documents/transactional/project-brief, version 2026.1.
- whatscene.in Search Console export, 28 days to 2026-08-23. Query-level impressions for the phrasings behind this piece, read from the committed export in data/search-console/. Run: data/search-console/2026-08-25-performance-28d.zip.
Revisions
- 25 August 2026 First published, as the public version of the client project brief template.
This page is revised in place rather than replaced, so its address does not change.