Vibe-coded app launch checklist.

Stop anonymous growth from turning into unrecoverable accounts, support tickets, or privilege leaks.

1. Verify every sign-in path you ship.

   Test email/password, OAuth, magic links, invite links, password reset, sign-out, and expired sessions in a fresh browser.

2. Confirm privileged routes check server-side identity.

   Client guards are UX only. API handlers, server actions, storage policies, and webhooks need their own authorization checks.

3. Write the account recovery path before launch.

   Document how you will restore access, revoke a compromised session, and help a paying user who lost an OAuth provider.

Vibe-coded apps often work in dev because service keys or permissive policies are hiding missing access rules.

1. Enable RLS on every user-owned table.

   Public tables are fine when intentional. Anything with user, workspace, billing, token, or private content columns needs explicit policies.

2. Test reads and writes as two separate users.

   Use real anonymous and authenticated clients. Confirm user A cannot select, update, delete, upload, or list user B data.

3. Keep service-role usage server-only.

   Search the shipped bundle and environment config for service-role keys, direct database URLs, and admin-only RPC calls.

A launch checklist should catch the boring mistake that burns the whole release: the wrong key in the wrong place.

1. Classify each variable as public, server-only, or local-only.

   Frontend-prefixed variables are public. Payment secrets, service keys, webhook secrets, and database URLs must never reach the browser.

2. Rotate anything that touched a prompt, screenshot, repo, or client bundle.

   Assume secrets pasted into chats, issue trackers, build logs, and generated code were copied somewhere durable.

3. Create a production env manifest.

   Store names, owners, required/optional status, and rotation notes without storing the secret values themselves.

Backups are not real until one restore has succeeded and someone knows how long it took.

1. Turn on automated backups before traffic arrives.

   Match retention to the damage window you can tolerate. Export critical tables if your plan does not cover point-in-time recovery.

2. Run a restore into a separate project or database.

   Measure restore time, check row counts, verify auth relationships, and make sure storage objects still line up with records.

3. Protect destructive admin actions.

   Require confirmation for deletes, archive before hard-delete, and keep a rollback SQL note for risky migrations.

Billing bugs are launch blockers because they either leak paid features or block users who already paid.

1. Test payment success, failure, cancellation, and refund states.

   Use provider test cards and subscriptions. Confirm UI, database state, receipts, and entitlement gates all agree.

2. Verify webhook signatures and idempotency.

   Reject unsigned events, process duplicate events safely, and persist provider event IDs before mutating user access.

3. Define the grace-period behavior.

   Know what happens on failed renewal, chargeback, paused subscription, plan downgrade, and trial expiration.

A launch is not just deploy. It is deploy, verify, roll back fast, and avoid breaking SEO paths after the first crawl.

1. Pin build commands, runtime versions, and install behavior.

   Do not let production discover a different Node, Bun, package manager, migration command, or environment mode than staging.

2. Create a rollback path that does not require improvising.

   Know how to redeploy the previous build, revert a migration, disable a feature flag, and freeze writes if data shape changed.

3. Check the traffic surface.

   Confirm canonical URLs, robots rules, sitemap inclusion, Open Graph image, 404 behavior, redirects, and page speed on mobile.

If agents helped ship the app, lock down what they can read, write, execute, and exfiltrate before production credentials exist.

1. Separate local, staging, and production agent credentials.

   Agents should not hold production service keys by default. Use scoped tokens and time-limited access for operational tasks.

2. Constrain file and command access for coding agents.

   Document repo ownership, destructive-command rules, test commands, secret-handling rules, and which paths require human review.

3. Review generated code for hidden network and auth assumptions.

   Search for broad CORS, permissive middleware, debug endpoints, insecure fetch targets, and TODOs around authorization.

You need enough signal to answer one question quickly: is launch traffic healthy or silently failing?

1. Track errors, latency, and conversion events from day one.

   At minimum, watch API error rate, auth failures, checkout failures, webhook failures, database errors, and signup-to-activation drop-off.

2. Create alerts for the few failures that matter.

   Page every time payment webhooks fail, login breaks, database writes spike, cron jobs stop, or API error rate crosses your threshold.

3. Keep a public support path easy to find.

   A clear contact link turns silent churn into actionable bug reports when real users hit edge cases you did not test.