There is a specific kind of silence that happens when a product demos perfectly on a Tuesday and falls over in front of paying customers on a Thursday. Nothing about the code changed. What changed is that reality showed up: a customer with a weird email address, a payment that half-completed, a phone from 2019 on hotel wifi. The distance between "the demo works" and "a business can charge money for this" is real work, and because we promise launches rather than demos, we keep that work in a checklist. Here it is, in full, so you can run it on your own product whether or not we ever meet.
Failure comes first
The first half of the checklist ignores features entirely and asks one question: when this breaks, what happens? Every system breaks. The difference between an incident and a catastrophe is whether anyone prepared. So before launch we verify backups exist, and then, and this is the part almost everyone skips, we restore one. A backup you have never restored is a hope, and hope is a poor database. We check that errors land somewhere a human will see them, with enough context to act, rather than dissolving into a log nobody reads. And we write down the rollback: if the release goes wrong, what exact steps put the previous version back, and how long do they take?
Money paths get walked, slowly
If the product takes payments, every payment path gets walked by hand before real cards do: the happy path, the declined card, the user who closes the tab mid-checkout, the refund, the subscription that renews, the subscription that fails to renew. Payment providers are reliable. The seams between your product and the provider are where money quietly leaks, and a leak found on launch day costs trust you cannot refund.
Permissions, or who can see what they shouldn't
Multi-user products get a permissions review with a simple format. We list every role, list every kind of data, and for each pair ask: can this role reach this data, and should it? Then we log in as the least trusted role and actively try to reach the things the matrix says are off limits. When we brought a fleet-compliance platform to production, this pass mattered more than any feature. An operator seeing another company's vehicles once is a bug report. Twice is a lost customer.
The unglamorous middle of the list
The middle of the list is not clever, and that is the point. Try the product on a cheap phone over throttled wifi. Send yourself every email the system can produce and read them like a stranger would. Put realistic load through it, several times what launch week should bring, and watch what slows down first. None of this requires a specialist. It requires an afternoon and the humility to look.
A launch is an operation, not a moment
The last section of the checklist is about people. Who is watching the system during launch week, and when they see something, who fixes it, within what time? What do users get told when something goes wrong, and who writes that message? We schedule launches for moments when a fast fix is possible, which in practice means never at 6pm on a Friday, however tempting the symbolism.
Why this is included, never an upsell
Some agencies sell launch readiness as a separate engagement, which has always struck us as billing twice for the word "done." Testing and launch preparation are part of the process itself. We don't sell the last 10% back to you. If a build price does not include the boring afternoon with the checklist, the build price is fiction, and you will pay the difference later with interest.
The security checklist for apps built with AI tools
If launch is close and this list made anything in your stomach drop, run the checklist this week. It costs an afternoon. And if you would rather have the people who wrote it run it with you, the intro call is 30 minutes, direct with Alexandru, and free. Worst case, you leave with a shorter list of things to fix.