The single biggest driver of project cost overruns isn't developer rate — it's scope discovered halfway through the build. A good brief front-loads that discovery instead of leaving it for week three.
1. What problem are you actually solving?
"We need a new website" is a symptom, not a brief. Are leads down? Is the current site embarrassing in sales calls? Is checkout abandonment high? The fix looks different depending on the real problem.
2. Who is this for, specifically?
"Everyone" is not an audience. A B2B buyer evaluating vendors reads a site completely differently than a retail shopper on their phone during a commute. Name the primary visitor and what they need to decide.
3. What does the current site get right?
Rebuilds often throw away things that were quietly working — a page that ranks well, a form that converts, an integration that took months to get right. Flag what should survive the rebuild.
4. What's the real deadline, and why?
"ASAP" isn't a timeline a developer can plan around. A launch tied to a trade show has different flexibility than a "sometime this quarter" refresh — say which one it is.
5. What's explicitly out of scope?
This is the one most briefs skip, and it's the one that prevents the most disputes later. If multi-language support, a members' area, or a mobile app aren't part of this phase, say so in writing.
Why this saves money
A detailed brief lets a developer scope accurately the first time, instead of padding the estimate to cover unknowns — or worse, quoting low and renegotiating mid-project. Fifteen minutes writing a clear brief routinely saves thousands in change-order costs later.