Write down what
good looks like.
What good looks like is the list of things that must be true before you call the app done. Your trade calls that acceptance criteria. This chapter ends with yours, in a file.
The list gets settled now, before anything is built, so it cannot bend to fit whatever you are shown.
Start today’s guided session now. Claude Code walks you through each step of this part, in your own project folder.
You do not write this list and you do not copy one. Claude Code asks you about ten short questions and builds the list out of your answers, in your words.
The questions come a few at a time, each with two or three answers you can tap. Tap one, or ignore them and say what you actually think.
Say it out loud rather than typing it. You set dictation up in Part 2 for exactly this. Talk for as long as you like, in whatever order it comes out. Rambling is useful here and tidy is not.
Three of about ten, drawn here so you recognise the shape when it arrives. This is this page’s own drawing and not a picture of your screen: yours will not read word for word like these.
You close the app and open it again the next morning. Should the boxes you typed in still be there?
You type kettle. Should it look inside the boxes, or only at the names you gave them?
How many boxes will you really have by the end of the move?
Every one of them is a question only you can answer. There is no right column, and an answer that is not on offer is still an answer: say it.
When the questions run out, Claude Code reads the finished list back to you and puts it in this file, in your project folder. You see the whole thing before anything is built.
Read it then. A line that is not what you meant is a line to change while nothing has been built against it.
One line will not occur to you, and it is the most expensive one to find out about late. Ask for it yourself, once the list has been read back to you.
Munim is building the same app on his own Mac, so the two results can be put side by side in Part 5.
Now ask,
in your own words.
You have your list. Now describe the app to Claude Code, in one go, in your own words. Expect one, two or three messages before it tells you the app is built.
When this chapter ends the app is built and running on your Mac. Chapter 05 puts it on your phone.
A thin description gets you a thin app. Claude Code builds what you tell it and guesses the rest.
A thick one still comes out rough. One message cannot carry a whole app, however much you put in it. That is the thing this part is built to show you.
Say as much as you can anyway. The more you say, the more there is to judge in chapter 07.
The map below opens out one person’s ask so you can see the kinds of thing a good one says: what it is for, how it should look and feel, what is on each screen, what each part does, and what it must never do.
This is one person asking for an app about lending books. Yours is about boxes, so none of these words are yours to use.
It is here for one reason only: to show how much a good ask says, and what it covers.
You do not have to write yours in this shape, and you do not have to cover all five branches, the five kinds of thing the map lists.
Now write yours, for the moving boxes app, in that much detail. Name no program, no language and no company: choosing those is Claude Code’s job, and naming one narrows what it can pick.
Say all of this out loud, the way you answered the questions in the last chapter. It is the longest thing you have to describe in the whole series.
Take as long as you like, in whatever order it comes out. Nobody is marking the sentences.
The box below is a starting shape, not a form you have to fill in. Copy it, paste it into Claude Code, and replace anything in square brackets with your own words, brackets included.
If a line does not apply to your app, delete it. If you want to say something the shape does not ask about, add it. Write as much as you like: more detail gets you a better app, and rambling is fine.
It is for [who uses it], and I use it on my iPhone.
It should look and feel [plain, warm, like what], with [colours], [how big the type is], and [whether anything is allowed to move].
Screen by screen: [what I see the moment it opens], [what happens when I tap a box], [whether there is a sign-in screen at all].
What each part does: [adding a box, in detail], [searching, in detail], [photographs, in detail].
When it is done, these must be true: [take the lines from your list].
It must never [what it must not do].
Can you build this for me?
The app is on your Mac now, and not yet on your phone. Chapter 05 puts it there.
Now inspect it,
against your list.
Nobody checked your list while that app was being built. Not Claude Code, not you. You asked once, it built, and the lines you wrote sat in a file nothing read.
That is a property of asking once. Not of Claude Code, and not of anything you did.
Ask it to check your list and it will. It was never asked to, and nothing in the quick build was going to ask.
Part 4 is where that changes, and it does not change by anyone remembering. There the app is built in packs: a pack is one small piece of work.
The method itself will not let a pack finish until its lines have been checked, one at a time, and the check is written down where you can read it.
So today you do that job by hand, one line at a time. This chapter ends with a score written beside every one.
Your list is in WHAT_GOOD_LOOKS_LIKE.md, the file that came out of chapter 03. Open your project folder in Finder to read it, or let Claude Code read it back to you with the paste line below.
Score every line PASS, FAIL or UNKNOWN, with the app open on your phone in front of you, never from memory.
UNKNOWN means the test could not tell you either way.
One of your lines will be about searching inside the boxes rather than only at their names. That one is easier to get wrong than it looks, so here it is as a question.
Some of your lines need nothing but a real box and a free hand. Do those first: pick a box up, and try to add it to the app with the hand that is still free.
Leave one line until last, the one you added at the end of chapter 03: a change to the app must never delete the boxes you have already put in.
Test it by doing exactly that. Ask Claude Code for one small change, start the app again on your phone, then look for your boxes. If they have gone, that line is a FAIL.
Claude Code walks you down the list and writes your answers down. It does not score the app for you, and nothing here does: you are the one holding the phone.
A list is yours to extend. If today showed you something your list never asked for, ask Claude Code to add it as a new line, then score that one too.
A FAIL here is not a bad result. It is the thing you came for: it names, in your own words, one thing that asking once did not give you.
Do not fix any failing line now. A fixed app is no longer evidence of what a build this quick produces, and Part 4 needs that evidence standing beside it.
One app.
One honest list.
You now have three things: an app running on your own iPhone, a list of what good looks like, and an honest score against it.
The score is the point. It names, in your own words, what the quick build did not give you.
One site diary entry now, while it is fresh. It records what the playbook did to you, and if the app came out better than you expected, that goes in too.
Part 4 builds this same app again, properly, in a project folder of its own. You take your list with you and score the new app against the very same lines.
Keep today’s app exactly as it is: the only record of what a build this quick produces.
End of Part 3 · The quick build