Skip to main content

R8. Launch checklist

What this page helps you do​

Run through the most important launch checks before you point real users at the app.

Why it matters​

Most painful launches are not caused by one advanced technical mistake. They are caused by a handful of basic things that were never checked together.

You should already have​

  • a deployed app or a deployment candidate
  • a domain plan
  • a rough sense of what data and secrets the app uses

Skip this page if​

  • the app is still at the idea or local-only stage

Then go back to S2. Quick start or H6. Deploy your app.

What to do​

Check these basics:

  • The app runs in production, not only locally.
  • The main user path works end to end.
  • The domain points to the right place.
  • HTTPS works without scary browser warnings.
  • Secrets are not stored in the repo.
  • Important data has a backup plan.
  • You know where logs live.
  • You can see production errors.
  • You have a rollback path.
  • Admin pages are protected.
  • Input is validated.
  • Abuse and spam are considered.

Then check app-specific needs:

  • payments
  • file uploads
  • background jobs
  • login and account recovery
  • AI usage limits and model failure handling

If you cannot verify a check, write that down honestly instead of pretending it is done.

Use three report buckets:

  • found
  • likely missing
  • could not verify

That same model works well for human self-audits and agent audits.

Common mistakes​

  • checking only the happy path
  • treating “we probably set that up” as done
  • launching with no named blockers list
  • leaving boring but high-risk items for “later”

Next step​

If you pass the basics, launch carefully and monitor the app. If not, fix the launch blockers first.

Advanced notes​

The agent layer in this repo uses this same launch logic. See agent/README.md and the checklists in agent/checklists/.