Your app works in the preview. You can sign up, click through the main flow and see your data. The question before launch is a different one: will it still work when strangers sign up, pay, make mistakes and, sometimes, try to break it?
That question has a long answer, because an app built with Lovable, Bolt, v0, Cursor or Claude Code is more than its screens. This checklist ranks what to verify by severity, so you know what has to be fixed before launch and what can wait a few weeks.
Why “it works in the demo” is not enough
A demo tests the happy path, with one user and with data you created yourself. Production adds other users, real money and failure modes that nobody clicks through by accident.
There is also evidence that speed of generation does not equal speed of safe delivery. A survey by the debugging company Undo, reported by LeadDev, asked 300 senior engineering leaders at large US and UK companies about the past six months. 81% said their organization had a production incident or outage linked to AI coding tools. The same respondents estimated that 35% of AI-generated code reaches production before the team fully understands it. Those are large companies with engineering teams, not solo founders, but the lesson carries over: code that nobody has read is code that nobody has checked.
SEV-1: data access and secrets
These are the findings that can expose customer data on day one. Check them first.
- Row level security on every table. The Supabase production checklist says it plainly: a table without RLS and sensible policies lets any client read and change its data. Enabling RLS is only the start. The policies also have to match what your app intends. Our article on Supabase row level security in Lovable and Bolt apps covers the most common mistakes to check for.
- Cross-user access. Create a second test account and try to open the first account’s records directly by URL or ID. If that works, no user will report it. They will just see someone else’s data.
- Secret keys in the browser. Any key that bypasses your access rules must stay on the server. Search the built JavaScript bundle, not only the source files.
- Admin accounts. Protect the accounts that control your backend and your code host with multi-factor authentication, and add a second owner so a single lost login does not lock you out.
Imagine a SaaS founder who launches a client portal on a Friday. Every screen works. On Monday a curious user changes one ID in a request and downloads another company’s invoices. Nothing in the demo would have shown this.
SEV-2: sign-up, email and payments
These failures rarely look like an outage. The site loads, but new users cannot get in, or they pay and get nothing. In a discussion on r/lovable, a developer who works on a monitoring tool described this pattern: the site is almost never down, but sign-up or checkout quietly stops working, and users leave instead of reporting it.
What to check, on the published URL and in a private browser window:
- Sign-up with a fresh email address. Confirm the email arrives and the link does not point to localhost or the preview domain.
- Password reset. It uses a different template and redirect URL than sign-up, so test it separately.
- Email delivery limits. Supabase recommends your own SMTP provider for auth email. Without one, its documentation lists a limit of 2 auth emails per hour, which a launch can exceed in minutes. Set up SPF and DKIM for your domain so the mails do not land in spam.
- Checkout end to end. A payment can succeed while the webhook that grants access fails. Then the money is taken and the user never gets what they paid for.
- AI features. Make one real request to every feature that calls an LLM API. Expired keys and empty credit balances often fail without any visible error.
SEV-3: operations you will need in week two
These do not block launch, but you want them before your first real problem.
- Backups and recovery. Know your plan’s backup options. Supabase notes that Free Plan backups cannot be downloaded and that low-activity Free Plan projects can be paused.
- Error monitoring. Even a free tier of an error tracker tells you when something throws, before a user does.
- Load and indexes. Add indexes for the queries you run often, and run a basic load test against a staging environment, not production.
- Repeatable deployments. Deploy database changes from your repository instead of by hand from a laptop, so production matches what you reviewed.
- Regression clicks after every change. Sign-up, login, checkout, contact form, one AI call. Automate this with a browser test tool once doing it by hand becomes a habit you skip.
What this means for your project
Work through the list in order of severity. SEV-1 items are launch blockers: if any check fails, fix it before real users arrive. SEV-2 items should be fixed before you spend money on marketing, because every lost sign-up costs you twice. SEV-3 items can follow in the first weeks, as long as you plan them.
Be honest about which checks you can do yourself. Clicking through sign-up and checkout needs no code knowledge. Judging whether access policies match your business rules, or whether a key in the bundle is safe, does. That is the core of a production readiness review. If the codebase has already become hard to change, the AI code rescue page and our note on deciding between refactor and rewrite are the better starting point.
Not sure where your app stands on this list? Book a free intro call and we will tell you honestly whether a production readiness review makes sense before your launch.