Most first briefs describe a solution instead of a problem — "I need an app with a dashboard and a chatbot" — because that's the language that sounds like it belongs in a brief. It isn't the useful part. The useful part is what's actually going wrong today, in enough detail that someone who's never met your business can picture it.
What a good brief actually contains
- The problem in plain words. What's slow, what's manual, what keeps going wrong — described as it happens today, not as a feature you've already designed to fix it.
- Who does this task, and how often. "My office manager does this for two hours every Monday" tells a developer more than any wireframe.
- What "done" looks like. A specific, checkable outcome — "a customer can book a slot and get a confirmation email" — not a feeling.
- What it has to connect to. The accounting package, the booking calendar, the spreadsheet everyone secretly still uses.
- Real constraints. Budget, deadline, anything you're not willing to change about how the business runs.
What to leave out
Specific technical choices you're guessing at — which database, which framework, whether it should be "an AI agent" — are usually worth leaving to whoever you hire. Naming a technology in a brief because you read about it somewhere can lock in a choice before anyone's checked it's the right one for your actual problem.
A developer asking questions back is a good sign, not a delay. It usually means the brief was specific enough to disagree with, which is more useful than a brief detailed enough that nobody has anything to say about it.
A one-page brief, in order
- 1One paragraph on the problem, as it happens today.
- 2Who's affected, and how often it comes up.
- 3What "fixed" looks like, in a sentence you could check against the finished thing.
- 4What it needs to connect to, and who holds the logins.
- 5Budget range and deadline, even rough ones — a range with no number in it wastes everyone's first meeting.
That's genuinely the whole document. The rest — architecture, feature breakdown, timeline — is what a good brief gets back from the person you send it to, not what you're expected to arrive with.