Launch walkthrough checklist
Function, experience, data, security — check item by item before launch. A reusable checklist and how to use it.
Function, experience, data, security — go through them one by one before launch. The checklist exists for the version of you that is rushing, when you will only click the path you know best — while a user finds, in the first hour after launch, that the button you never clicked whitescreens.
What you'll run into:
- Within an hour of launch, users find a button you never touched that whitescreens
- You ship, then remember the empty state was never built — new users land on blank pages
- You keep testing with the same old account; a brand-new user's very first step has been broken for ages
- You rolled back twice, and both times the cause was something you said "we'll check next time"
Four categories, one list
Lock the checklist into four categories, in a fixed order: Function → Experience → Data → Security. If an earlier one fails, the later ones do not matter; the last one is a single-veto gate.
| Category | Check these | How you know it passes |
|---|---|---|
| Function | Main flow end to end; all four states at every async spot; retry after failure without losing filled content; run both overlong content and zero records | A person can finish it without your help |
| Experience | Full pass with a brand-new account; narrow-screen pass; messages say what happened and what to do next; destructive actions are undoable; no "test" or "TODO" placeholder copy shipped | A stranger knows what to do without asking |
| Data | Key events are reported; failures carry a reason; attributes include a joinable id; dashboard or query is ready | You can see a curve on day one |
| Security | No keys or tokens in frontend code; switch accounts and try to read someone else's data; permission checks also done on the backend; user input escaped before display | Try to escalate privileges — and fail |
Keep the checklist short enough that you'll actually run it every time. Under twenty items, walkable in fifteen minutes — only then does it become a habit. Write fifty and nobody reads it by the third launch.
How to run the walkthrough
- Switch to a brand-new account. Old accounts carry historical data and naturally skip the empty state and onboarding — exactly the two places new users hit first.
- Narrow the window once. No real device needed — drag the browser to phone width and most layout problems surface immediately.
- Throttle the network once. Limit to 3G in the browser devtools and you can see at a glance whether loading and timeout states are handled.
- Take "the wrong path" once. Fill in wrong values on purpose, leave fields empty on purpose, double-click submit on purpose — see how it responds.
- Log as you go, don't fix as you go. Note issues first; triage them all after the pass. Start editing code mid-pass and the whole walkthrough is wasted.
What blocks the launch
Not every item carries the same weight. Sort them into two tiers — it takes only seconds to decide:
- Blockers · do not ship without them: data loss or wrong money charged; one user seeing another user's data; secrets leaked in the frontend; main flow broken; an error with no message at all.
- Backlog · fine to ship: a spacing issue on narrow screens; the empty-state illustration not drawn yet; copy that could be smoother; a spinner instead of a skeleton loader; one minor event missing from analytics.
The five blockers share one trait: when they go wrong, users get hurt, and you cannot repair the damage afterward. The backlog items are ugly, but they can wait for the next version. Run the experience tier against the ten usability heuristics and you cover most of the "forgot to look" cases;nng-heuristics run the security tier against the OWASP common-risk list.owasp
Let AI self-check first
If the code was written by AI, have it self-check against the list before you walk through it yourself. It is good at structural gaps like "this branch has no error handling," and bad at judging "will a user understand this hint."
PROMPT · Pre-launch self-check
Check the feature you just built against the checklist below. Give a verdict for each item. Do not change code.
## Function
- Does the main flow complete? Does every async spot have empty, loading, error, and normal states?
- Can users retry after a failure, and does the filled content survive?
- What happens with zero records and with overlong content?
## Experience
- What does a brand-new user see on their first visit?
- Does the layout still hold on a narrow screen?
- Does the error message say what happened and what to do next?
## Data
- Are key events reported? Do failures carry a reason?
## Security
- Are any secrets hard-coded in the frontend?
- Is permission checking done only on the frontend?
- Is user input escaped before being displayed?
Output format: a verdict of "pass / fail / unsure" for each item. For any "fail", give the file and line number.
List the "unsure" items separately — I will review them by hand.
This checklist is a good fit for your project's rules file — have it run itself before each delivery so you do not repeat it every time.