Recap and Practice

Key takeaways

• Shipping is a workflow, not a moment: deploy, observe, patch, repeat — and make rollback something you've already tested once.
• Run the pre-launch checklist before you announce anything, and have the AI verify each item instead of trusting your memory.
• Let measurement drive optimization — a Lighthouse report beats a hunch about what "feels slow" every time.
• Secrets live in production config, never in the repo; .env is gitignored and .env.example stays current.
• The first version is a hypothesis; real users are the experiment, so iterate in small, fast fixes.

Try it

Take an app you've deployed (or deploy a tiny one now) and run the full pre-launch checklist against it line by line. For every box you can't honestly tick, paste the failing item to the AI and ask for the smallest change that closes the gap. Finish by clicking a deep link on the live site — not just the homepage — to confirm production behaves like dev.

Prompt of the chapter

Here is my deployed app and its stack: [describe app + hosting + services].
Act as my launch reviewer. Walk this pre-launch checklist item by item
and, for each, tell me how to verify it on the LIVE site (not in dev):
- production URL loads over valid HTTPS on the custom domain
- all secrets set in production; none committed to the repo
- core happy path (sign-up, login, main action) works in production
- payments tested end-to-end including the webhook (if any)
- error tracking and uptime monitoring are live
- I can roll back, and have tested it once
- mobile layout works on a real phone
- database backups are enabled
For every item that fails, give me the SMALLEST change that fixes it.
Do not assume anything passes — make me prove each one.