5.1
Brief Before Build
Why this exists
You're about to build something real, and the instinct is to open Claude Code and say "build me a site." That works for about ninety seconds, and then you're in a conversation where every message is a correction and the thing gets steadily worse.
You already know why from 2.3 — your first prompt is worth more than every prompt after it. A brief is that idea applied to something bigger than one message.
The idea
If you can't describe it, it can't build it. And you don't know what you want until you've written it down.
That second half is the part people miss. Writing a brief isn't paperwork you do before the real work. It's how you find out what you're actually asking for — half the things you thought were obvious turn out to be decisions nobody has made.
A brief that works has four parts:
| Part | The question it answers |
|---|---|
| What it is | One sentence a stranger would understand |
| Who it's for | And what they're trying to do |
| What it must have | The things that make it work at all |
| What good looks like | How you'll know it's finished |
That last one is the one everyone skips and it's the one that saves you. "A one-page site with my details and a contact form that emails me" is finishable. "A nice site for my business" is not — there's no version of it that's done.
Two rules that keep briefs useful:
Say what it must have, not how to build it. "People can contact me without me publishing my email" is a requirement. "Use a Formspree integration" is a solution, and you don't know enough yet to pick one. Let it propose.
Cut it in half. Every first brief is too big. The version you should build is the smallest one that would actually be useful, because you'll learn more from finishing something small than from abandoning something ambitious. You can add to it. You cannot un-abandon it.
For this level, build something genuinely small — a one-page site, a personal dashboard, a tool that does one job. Not something you need. Something you can finish, break on purpose, and fix. The point of Level 5 isn't the thing you build. It's that Level 6 asks you to operate a system, and that's much harder if you've never built one.
Do
- Pick something small and real you could finish this week. A one-page site, a simple tool, a dashboard for something you check often.
- Make a file called
brief.mdin a new project folder. - Write What it is — one sentence. If you can't, you don't know yet. Keep going until you can.
- Write Who it's for and what they're trying to do. "Me, checking X quickly" is a fine answer.
- Write What it must have — the things without which it doesn't work. Requirements, not solutions.
- Write What good looks like — the specific state where you'd stop.
- Now cut it in half. Delete the parts you'd like to have. They can come back later.
- Give the brief to Claude Code and ask: "What's ambiguous in this? What would you have to guess at?" Fix what it names.
Step 8 is the cheapest quality check in the whole course. It'll find the holes you can't see because you know what you meant.
Done when
Never do
Don't start building before the brief is written. Not because process is virtuous, but because the alternative is discovering what you wanted through twenty rounds of correction — and by then, as you saw in 2.3, the conversation is carrying a bad direction it can't shake.
Ten minutes on the brief buys back an hour.