Taking a vibe-coded app to production: the checklist we use

An app built with Lovable, Bolt, Replit or Cursor can look finished long before it's safe to hand to strangers. The screens work. What's missing is usually invisible: who can read which records, where the secret keys live, and what happens when a payment fails at 3am.

This is the list we go through before an AI-built app takes real users or real money. You can check most of it yourself in an afternoon, even if you don't write code. Where a fix needs a developer, it says so.

Your data

• Every table has access rules switched on. If your app uses Supabase, open each table and check that row-level security is enabled. The key your app sends to the browser is public by design, so these rules are the only thing deciding who can read what.
• The rules say what you mean. "Signed-in users can read this" is not the same as "people can read their own records". Make a second test account and try to open the first account's records, for example by changing an ID in the address bar.
• Nothing private loads when you're signed out. Open the app in a private window without signing in and try the pages that should need an account.
• Backups exist, and you've restored one. Check that your database plan includes backups, then restore one into a copy. A backup you've never restored is a guess.

Your keys and accounts

• Secret keys never reach the browser. Anything named "service", "secret" or "admin" belongs in server code, not in the app your visitors download. In Lovable projects, and other apps built on Vite, any setting whose name starts with VITE_ is readable by anyone who opens the page source.
• Any key that was ever pasted into a chat, a prompt or a public repository gets replaced. Every service lets you issue a new key from its dashboard; the app then needs the new one in its settings, and the old one switched off.
• Everything sits on accounts you own. The domain, hosting, database, payment account and code repository should be in your name or your company's, with a second person who can get in if you're locked out.

Payments

• The server decides what someone paid for. Prices and plan checks that only happen in the browser can be changed by anyone who opens the developer tools.
• Payment events are checked, and handled once. If you use Stripe, the code that receives its notifications should check Stripe's signature and cope with the same notification arriving twice, because Stripe resends any it isn't sure you received. This fix needs a developer.
• The failure paths are tested: a declined card, a cancelled subscription, a refund. Stripe's test mode has card numbers that fail on purpose, and you can cancel and refund test payments from its dashboard.

When something goes wrong

• You hear about errors before your users do. An error tracker on the app and the server, with an alert for anything new, turns "a customer emailed us" into "we fixed it this morning".
• Every email arrives. Sign up from a fresh address and trigger every email the app sends: welcome, password reset, receipts. If any land in spam, your domain's email settings (SPF, DKIM and DMARC) need setting up.
• Someone else could pick it up. The code is in a repository you own, there's a short note on how to run it, and changes go through that repository rather than straight into the live app.

What this list leaves out

Speed under real traffic, accessibility, and legal pages such as a privacy policy matter too, but they depend more on what your app does. This list covers the part that decides whether your first users can trust it with their data and their money.

If you'd rather not do it alone

An AI-built app rarely needs a rewrite to pass this list. Usually it needs these gaps closed, on accounts you own, while the flow you've already built stays as it is. That's what we do in 7 to 14 days, at a fixed price agreed before you pay anything.

Not sure you need help yet? Read when it's time to bring in a team first.