Write Down What Good Looks Like First

Five to Ten Sentences

Before you build, write down the things this must get right. Not a document — a short list of plain sentences, five to ten of them. Each one should be something you could check by hand in under a minute. "A visitor can submit the form and I get an email within a minute." "Nobody can see anyone else's bookings." "Entering a date in the past is refused with a clear message." "It is usable on a phone." That list is your definition of working. Everything else — how it looks, what it is called, which shade of blue — is preference, and preference is allowed to change. This list is not, unless you deliberately decide to change it.

• Five to ten plain sentences, each checkable by hand in a minute
• Cover the core action, the boundaries, and the obvious wrong inputs
• This list is what "working" means; everything else is preference
• Keep it in one file next to your spec, not scattered in chat history

Why Before Matters

Writing the list before you build is the whole trick, and it is easy to skip. Written afterwards, the list mysteriously describes what you happen to have. You look at the screen and write down what it does, which tests nothing. Written before, it comes from what you actually need, and some of the items will fail. That is the point. It also protects you from a subtler drift. As you build, your idea of a good result quietly reshapes itself around whatever turned out to be easy. A list written while your eyes were clear is a record of what mattered, before the building process started negotiating with you.

• A list written afterwards just describes what you got
• Items that fail on the first run are the ones earning their place
• Your standard for good drifts towards what turned out to be easy
• The list is a record of what mattered before the building started

Include the Nevers

At least a couple of items should be things that must not happen. These are the ones nobody notices when they break. "One user must never see another user's data." "Nothing is emailed to a customer without me pressing a button." "It must not let the same slot be booked twice." Positive checks confirm the thing you were looking at anyway. Negative checks catch the failures that are invisible from the outside. Nobody complains about seeing data they should not have seen, because they are not aware they should not have seen it. If a never-item is genuinely hard to check by hand, treat that as a signal. The feature deserves more care than a prototype normally gets.

• Include two or three things that must never happen
• Negative failures are silent; nobody reports seeing too much
• Double-booking, double-charging and cross-visibility are classic silent failures
• A never-item you cannot check by hand is a feature that needs real help

Keep It Short Enough to Use

A thirty-item checklist will be run twice and abandoned. Ten items that take five minutes will be run for months. Ruthlessness here is a feature, not laziness. Pick the things that would actually matter if they broke, and let the rest go. You can add an item later, when something breaks in a way you did not anticipate. In fact that is exactly when to add one, since a failure that surprised you is proof of a gap in the list. A checklist that grows slowly, one real failure at a time, ends up fitting your specific project far better than a comprehensive one copied from somewhere else.

• Ten items you will actually run beat thirty you will abandon
• Add an item whenever something breaks in a way you did not predict
• The list should grow from real failures, not from imagined completeness
• If a run takes more than about five minutes, it is too long to survive

Try It Yourself

You have just read why the list has to come before the building. So stop here and write yours — for the project you are actually making — before you change another thing.

My checklist:
1. [the core action, end to end — who does what, and what happens]
2. [what you receive when it works — the email, the record, the message]
3. [what a wrong input gets — refused, with a clear message]
4. [something that must work on a phone]
5. [one more thing that would genuinely matter if it broke]

NEVER: [the one thing that must not happen, even once]