Free checklist
Is your AI-built app ready to launch?
Answer 11 questions about your Lovable, Bolt, Replit, v0, or Cursor app and get a readiness score, the risky gaps ranked worst first, and how to fix each one yourself.
The checks cover what AI builders most often leave open: Supabase access rules, secret keys, logins, Stripe webhooks, backups, and who owns the accounts. Your answers stay in this browser.
0 of 11 answered
Answer 11 more questions to see your score, what to fix first, and how.
What each check means, and why AI-built apps miss it
An app can look finished in the builder's preview and still fail these checks, because the preview only ever has one user: you. Here's what each one means in plain words.
01 · Critical
Row Level Security on every table
Supabase lets the front end of your app talk to the database directly, using a public key that every visitor's browser can see. Row Level Security is what decides which rows that key can read or change. Supabase's own guide says to enable RLS on every table in an exposed schema, because a table without it is readable and writable by any role that has a grant on it.
Why AI builders miss it. The app works in the preview whether the policies are right or not, because you're testing it logged in as yourself. A policy can also be switched on but too loose, such as one that lets any logged-in user read every row. In May 2025, CVE-2025-48757 was published for Lovable-generated apps whose RLS policies were insufficient, letting unauthenticated visitors read or write database tables. Lovable disputes the record, saying each customer is responsible for protecting their own app's data. Either way, it's yours to check.
02 · Critical
Secret Supabase key kept out of the browser
Supabase gives you two kinds of key. The publishable key (the anon key, in older projects) is meant to be public, and RLS limits what it can do. The secret key, or the older service_role key, skips RLS entirely. Supabase's docs say it belongs only in backend code you control, and never in a browser, a shipped app, or source control.
Why AI builders miss it. When a query fails because of a policy, the quickest way to make the error go away is to swap in the key that ignores policies. Ask an AI tool to "make it work" and it can do exactly that, and the app looks fixed.
03 · High
Other secret keys on the server only
A secret key lets whoever holds it spend money or read data on your account. Secret keys belong in your host's environment variables, read only by server code, and never in the code a browser downloads or in your Git history.
Why AI builders miss it. Calling an AI or payment API straight from the page is the shortest path in a demo, so that's often what gets built. Keys also get pasted into code while debugging and committed to GitHub, where they stay in the history after you delete them.
04 · High
Sign-up, login, and password reset on your real domain
Login emails contain links back to your app. Supabase uses a Site URL and a list of allowed redirect URLs to decide where those links go, and its docs say to change the Site URL from http://localhost:3000 to your production address before going live. Supabase's built-in email sender is for testing: its docs say it isn't meant for production, only sends to your project's team, and has a low hourly limit.
Why AI builders miss it. Everything gets tested in the builder's preview, so links point at the preview or at localhost. It works for you, then breaks for the first real person who signs up on your domain.
05 · Critical
Stripe webhooks verified and safe to repeat
Stripe tells your app that a payment went through by calling your webhook. Stripe's docs say to verify each event's signature, because without it an attacker could send fake events to trigger orders or account access. They also say the same event can arrive more than once and events can arrive out of order, so your code should track the event IDs it has processed.
Why AI builders miss it. In testing, each payment sends each event once, in order, so a handler that trusts every request seems fine. Signature checks also need the raw request body, which some frameworks change before your code sees it, and the quickest way past that error is to remove the check.
06 · Medium
Separate test and live setups
Staging is a copy of your app with its own database and test payment keys. New changes go there first, so a mistake breaks the copy and not your customers' data.
Why AI builders miss it. An app in an AI builder usually has one project, and each prompt edits it directly. That's quick for a demo. Once you have users, one bad prompt can change a table or delete data in production.
07 · High
Backups and database migrations
A backup lets you restore data after a mistake. Migrations are your database changes saved as files in the code, so you can rebuild the database or apply the same change to staging and production. Supabase's docs list daily backups on paid plans, with the last 7 days available on Pro, and recommend that free-plan projects export their data regularly.
Why AI builders miss it. Builders often change the database directly when you prompt them, so the only record of its structure is the live database itself. Many apps also launch on a free plan without anyone checking what that means for backups.
08 · Medium
Error alerts and logs
Error monitoring, such as Sentry, records crashes in the browser and on the server with enough detail to fix them, and alerts you when they happen. Logs show what your server functions, database, and webhooks actually did.
Why AI builders miss it. In the builder, you see errors in the preview as they happen. Once real users are on their own phones, nobody sees the errors unless something records them.
09 · Medium
Rate limits and abuse protection
A rate limit caps how often one person or bot can call something. A bot check such as a CAPTCHA stops scripted sign-ups. A spending cap stops an AI or email bill from growing without limit.
Why AI builders miss it. Abuse doesn't show up in a demo with one user. Every AI call costs money, and a public endpoint that calls an AI model without a limit is easy to run up by script.
10 · High
You own the code and the accounts
Whoever owns the accounts controls the app. You should be the owner of each one, with any developer or freelancer added as a member you can remove.
Why AI builders miss it. Apps often start in the builder's own cloud or in a freelancer's account. Until the code is exported to a GitHub repository you own, it may only exist inside the builder.
11 · Medium
Speed with real users and real data
An app with a few test rows can be fast for reasons that stop being true once the data grows. Slow spots usually come from missing database indexes, loading whole tables instead of a page at a time, or running one query for every item in a list.
Why AI builders miss it. Builders write code that works on the data in the preview. Nobody notices a query that loads every row until there are enough rows to make it slow.
Fix it yourself, or get it checked
If your app has no real users or payments yet, work through the fix list yourself, critical items first. Most of the medium items can wait until you have people using it.
If you're about to take payments, launch publicly, or show the app to investors, get the critical checks confirmed by someone who didn't build it. That's what the Launch-Ready Review is for: $900–1,500, 3–5 days, a written report, and a fixed price for each fix. If the app already has users and needs more than fixes, see AI-built app rescue. Not sure you own all your accounts? The handover checklist lists what to get in your name.
FAQs
Does a good score mean my app is secure?
No. The score is only as good as your answers, and the critical checks are easy to get subtly wrong: an RLS policy can be switched on and still let any logged-in user read every row. Treat a good score as "the basics are covered", then have someone who didn't build the app test the critical checks the way an outsider would.
How is the readiness score worked out?
Each check is weighted by how much damage it can do: critical checks count three times, high twice, medium once. Yes scores a check in full, partly scores half, and no or not sure score nothing. Checks that don't apply are left out. Any open critical check means "not ready", whatever the number says.
Doesn't Lovable or Supabase check this for me?
Partly. Supabase's Security Advisor flags tables without RLS and other common problems, and some AI builders now run their own security scans. They're worth running. But they can't know who should see which data in your business, whether your password reset emails arrive, or whether your Stripe handler can be fooled. Those need someone to check your app specifically.
I'm not technical. Can I fix these myself?
Some, yes. Account ownership, the Site URL and redirect settings, custom email sending, backups, and spending limits are mostly dashboard settings. RLS policies, secret keys in the code, and Stripe webhook handling mean reading code. For those, copy the fix list from your result and hand it to a developer, or ask your AI builder to make each change and then test it yourself.
What does the Launch-Ready Review cost?
$900–1,500, fixed before I start, and it takes 3–5 days. I check Supabase access rules, secret keys, logins, Stripe webhooks, hosting, and backups on your actual code and accounts, and send a written report with a fixed price for each fix. If you continue with me, the review fee comes off the next step.