← Blog

The pre-launch checklist for vibe-coded apps

Vibe-coded apps are unusually good at looking finished. The build passes, the demo works, it deploys. None of that tells you whether it’s safe to put real users and real data behind it. Before you launch, walk this list — it’s the boring, invisible stuff that actually takes apps down, and every item is something you can check yourself.

Security

  • No secrets in the frontend. Search your bundle, repo and git history for secret keys, database URLs and tokens. Public keys (Supabase anon, Stripe pk_) are fine; anything secret / service / sk_ must be server-side only. (how to find them)
  • Privileged routes check auth on the server. Every /admin page and sensitive API endpoint verifies the session server-side — not just by hiding a button.
  • Input is validated server-side. The server never trusts the shape or contents of what the client sends.

Data & multi-tenancy

  • Database rules are on and scoped. On Supabase, Postgres or Firebase, every table/collection has rules scoped to the user — not off, not test mode, not USING (true) / allow if true.
  • The tenant boundary is server-derived. Who-can-see-what comes from the session, never from an id the client sends.
  • Test it as a second user. Log in as two different accounts and confirm one cannot see the other’s data.

Scale

  • Lists are paginated and indexed. No query loads an entire table; no N+1 firing one query per row.
  • Costly endpoints are rate-limited. Auth, sign-up, email and any LLM or third-party call has abuse protection, so it can’t be hammered or run up a bill.

Infrastructure

  • Prod and dev are separated. Different credentials and databases; a mistake in development can’t touch real data.
  • You have a backup — and you’ve restored from it. An untested backup is a guess, not a safety net.

Deployment

  • You can roll back. A bad deploy can be reverted quickly, not just fixed-forward under pressure.
  • Dependencies are current. You’d notice a known-vulnerable package before it’s in production.

Does it do what you meant?

  • Unhappy paths work. Wrong password, expired session, duplicate submit, empty and error states — not just the demo happy path.
  • A second pair of eyes. Someone other than you — and other than the AI that built it — has read the code for security and correctness.

The one item you can’t do alone

That last point is the catch. The author and the AI that wrote the code share the same blind spots that created the bugs — which is exactly why asking the same model “is this production-ready?” is worth almost nothing. A real second read is the only item on this list you can’t reliably do by yourself.


Want this as an instant, scored version? Run the free 2-minute self-check — the same areas, with your specific risks flagged. And when you want a human to actually verify it rather than self-assess, a seniorgrade audit is a senior engineer reading your real code: $49, prioritized report within 48 hours.