A model can produce a settings page in seconds. It cannot tell you whether your production email lands, your webhook retries, or your backup restores.
Those facts live outside the code. They must be tested in the world.
If a check requires production, a screenshot of localhost is not evidence.
Identity and access
Create two ordinary accounts and one administrative account. Try to reach one user’s records from the other. Check every server action and API route, not only the buttons that hide them.
Then test sign-up, verification, sign-in, sign-out, password reset, expired links, and deleted accounts. Decide what happens to active sessions after a password change. If the app supports teams, test invitations twice and after they expire.
The dangerous assumption is that an authentication library also supplies authorization. It usually does not know which invoice, project, or file belongs to whom. That rule is yours. Run the two-account authorization test across routes, files, exports, roles, and background jobs before inviting real users.
Payments
Use the payment provider’s test mode, then make one controlled production purchase if possible. Check success, cancellation, decline, duplicate submission, delayed confirmation, refunds, plan changes, and webhook retries.
Treat the provider’s server notification as the source of truth. A browser returning to a success page is not proof of payment.
Make the price, renewal period, trial terms, taxes, and cancellation path visible before the user commits. A technically successful charge can still be a bad launch.
Data
List the data you collect and why. Remove fields kept “for later.” Check that secrets stay on the server and private records do not enter logs, analytics, URLs, or client bundles.
Create, edit, export, and delete a real-looking record. Then restore one from backup. “Backups enabled” describes a setting. “Record restored on this date” describes a capability. The pre-launch backup drill shows how to prove it without putting the only production copy at risk.
Email and recovery
Send production email to addresses at several major providers. Read it on a phone. Check the sender, reply path, links, expiry, plain-text version, and what information appears in the subject line.
Every critical flow needs an exit: lost password, lost second factor, failed payment, broken import, accidental deletion. If recovery requires the founder, publish a support route and rehearse the decision.
Operations
Know where errors appear. Trigger one on purpose. Confirm that an alert reaches a person and contains enough context to act without exposing user data.
Set resource limits. Add timeouts. Make repeated requests safe where money or data can change. Write a short rollback note before deployment, while the path is still obvious.
For model calls and other metered services, run the AI cost-spike launch test across duplicate submission, retries, agent loops, large inputs, queue delivery, anonymous access, and per-tenant limits.
The final pass
Use a fresh device on the public domain. Complete the core job. Pay. Sign out. Recover access. Delete the test data. Check the logs.
A vibe-coded app is not ready because the code looks finished. It is ready when the important promises have survived contact with production. If the deployed version already behaves differently, use the production boundary debugging order first.