What “launch-ready” actually means: the 9-point checklist

“Launch-ready” doesn't mean the features work. It means the app survives contact with real, careless, occasionally hostile users — on the worst day, not the demo day. Here's the checklist I run before I'd tell a founder to press go.

Almost every app I tear down works fine when you use it. You click the happy path, in the right order, with good data. Real users don't. They double-tap submit, paste emoji into the price field, lose signal mid-payment, and refresh at the worst possible moment. Launch-readiness is just: does it hold when they do?

The nine things I check, grouped by what actually kills launches.

If one thing breaks, let it not be these. A bug in a settings page is an annoyance; a bug in signup, login, or checkout is lost revenue and lost trust in the same second.

1. 01
   Auth survives the edges

   Wrong password, expired session, refresh mid-flow, OAuth cancel, back button — none should dead-end or leak you into a half-logged-in state.
2. 02
   Payments handle failure, not just success

   Declined cards, double-submit, closed tab after pay, webhook arriving late. The money path needs idempotency or you'll double-charge — or worse, deliver free.
3. 03
   Forms forgive humans

   Trim whitespace, validate on the server, keep the user's input on error. Never make someone retype everything because one field was wrong.

These don't show up in a demo. They show up when a stranger looks, or when more than three people arrive at once.

1. 01
   No secrets in the frontend

   Grep the bundle for keys. Anything the browser can read is public — covered in depth in the security write-ups.
2. 02
   Errors fail closed and quiet

   Catch them, log detail server-side, show the user a calm message — not a stack trace and a file path.
3. 03
   Rate limits on auth and paid calls

   Login, password reset, and anything wrapping a paid API need a ceiling, or one script runs your bill or your inbox.

1. 01
   First-load performance

   A slow first paint on mobile loses people before they see the value. Check on a real phone on cellular, not your desktop on fibre.
2. 02
   Mobile actually works

   Tap targets, keyboard covering inputs, viewport bugs. Most traffic is mobile; most demos are desktop.
3. 03
   The empty state isn't a dead end

   Brand-new users see zero data. If the empty state is blank or broken, that's the first impression — and often the last.

It's not “does it work when I use it” — it's “does it hold when someone who doesn't care about it does.”

— The launch-readiness test, in one line

Run those nine before you press go. If you want a second pair of eyes on them, that's exactly what a teardown is for.