Lesson 003Field guide · Build With AI
Writing a Build Brief
Describe what you want clearly enough that AI can help build it.
You'll learn
- Why "build me an app" goes nowhere — with AI or anyone else
- The seven parts of a build brief
- How to tell a vague ask from a buildable one
- How the brief becomes the foundation of your first prompt
01Section
Why "build me an app" goes nowhere
Imagine hiring a carpenter and saying "build me some furniture." You'd get something — a table, maybe, in a size you didn't want, in wood you didn't pick. Not because the carpenter is bad, but because you handed over all the decisions along with the job.
The ask that produces the wrong tool
"Build me an app that helps me manage my clients." Manage how? Which information? What does it do when a client is added? What must it never do? An AI assistant will answer every one of those questions with a guess — and build the guesses.
If you've taken the prompting lessons, you know this pattern: AI fills every gap with a guess aimed at the average. For a paragraph, a wrong guess costs you an edit. For a tool, wrong guesses get built — and you don't discover them until you're staring at software that does the wrong thing confidently.
The fix is the same one professionals use before any build: write down what you actually want, before anyone — human or AI — starts making it.
Checkpoint
02Section
The seven parts of a build brief
Plain-language definition
Build brief — a short, plain-language description of a tool — what problem it solves, for whom, what goes in, what comes out, and how you'll know it's done. Half a page is plenty.
Seven parts, each answerable in a sentence or two. Here they are, filled in for Sam's lawn-care quote calculator. It has outgrown last lesson's spreadsheet version — Sam now wants a ready-to-text customer message on a phone, and that custom formatting is code territory:
The two parts beginners skip
"Must not do" keeps the tool small — it's your scoping decision made permanent. "Done when" stops the endless-tinkering trap: without a finish line, no tool is ever finished.
Checkpoint
03Section
Vague vs. buildable
The difference between a wish and a brief is whether someone else could build the right thing from your words alone. Compare:
A wish
Build me something to handle quotes for my lawn business.
A brief
Problem: I recalculate quotes by hand and make mistakes. User: just me, on my phone. Inputs: lawn size, extras, travel distance. Output: one total price plus a one-line text for the customer. Must do: my pricing rules, rounded to the nearest 5. Must not do: no accounts, no stored data. Done when: three real quotes match my by-hand math.
The wish makes the AI decide everything. The brief leaves it exactly one job: building.
A quick honesty test for any part you've written: could two reasonable people read it and picture different tools? Then it's still vague. "Handle quotes" fails the test. "One total price, rounded to the nearest 5" passes.
Pause and think: Say your tool idea out loud in one sentence. Which of the seven parts does that sentence already contain — and which are still living only in your head?
Checkpoint
04Section
The brief is your prompt foundation
Here's why this format is worth the ten minutes it takes: the finished brief is the prompt. Paste it into any AI coding tool with one line on top — "Help me build this, one small step at a time" — and you've given it everything a good prompt needs: the task, the context, the constraints, and the definition of success.
It also outlives any single tool. Products change, assistants come and go — a clear description of what you want works in all of them, this year and next.
The build brief template — fill it in and keep it
BUILD BRIEF Problem: [the repeated task or pain this solves — one or two sentences] User: [who uses it, on what device, in what situation] Inputs: [exactly what goes in, listed] Outputs: [exactly what comes out, listed] Must do: [the non-negotiable behaviors and rules] Must not do: [features and behaviors this version deliberately excludes] Done when: [a concrete test you can run to call it finished]
Key takeaway
Ten minutes of brief-writing replaces hours of building the wrong thing. The brief is the single highest-leverage artifact in this entire path.
Checkpoint
Prompt exercise
Get interviewed into a finished brief
Copy this prompt into ChatGPT, Claude, Gemini, Copilot, or whichever AI tool you have access to — the website doesn't run AI itself. Instead of filling in the template alone, let the AI interview you: answering questions is easier than staring at blank fields.
I want to write a build brief for a small personal tool. Interview me one question at a time to fill in these seven parts: Problem, User, Inputs, Outputs, Must do, Must not do, Done when. Push back if my answers are vague — if two people could picture different tools from my words, ask a follow-up until it's concrete. If my scope creeps beyond one core job, point it out and suggest what to move to "Must not do." When all seven parts are solid, output the completed brief under the heading BUILD BRIEF in a clean format I can copy and save.
Reflection: Read your finished brief as if a stranger wrote it. Could you picture the exact tool? If yes, you're ready to build from it — hold onto it, the capstone uses this format.
Quick check
3 quick questions — no pressure
There's no pass or fail here. Answer them all, and we'll show you the answers either way.