AI app builders are good at one thing: getting a working demo on screen in days. What they don't handle well is everything a demo never shows.
A demo only has to work for you, on the happy path, with test data. A launched product has to work for strangers, with real data and real money, including when something goes wrong at 2am.
We take over a lot of these apps, and the same problems come up again and again. So we turned them into a checklist. Go through it before you invite real users. You don't need to be a developer for most of it; where you do, the item says what to ask.
Prefer to click through it? The free launch check asks the same twelve questions, adds up your answers and shows what to fix first.
Security
1No secret keys in the browser
Anything in your frontend code is public. Open your live site, open the browser's developer tools and search the loaded JavaScript for words like key, secret or sk_.
Some keys are meant to be public, such as Stripe's publishable key or Supabase's anon key. Secret keys, service-role keys and AI provider keys are not. If you find one, move that call to a server function and replace the key, because it has already been exposed.
2Users can only see their own data
This is the most common serious problem we find. Create two test accounts. Log in as the first, open one of its records and copy the link. Now log in as the second and open that link. If you can see the first user's data, your access rules are missing.
On Supabase, check that row-level security is switched on for every table, and that every table has policies, not just the ones you remembered.
3Admin pages are protected on the server
Hiding an admin button doesn't protect the admin page. Try opening admin addresses while logged in as a normal user, and while logged out. The check that decides who is an admin has to happen on the server or in the database, never only in the browser.
Data
4The server checks what it receives
Validation in the browser is a convenience for honest users. Anyone can send requests straight to your backend and skip your form. Prices, quantities, roles and anything else that matters must be checked, or worked out, on the server.
5Backups exist, and you've restored one
Find out where your database backups are, how often they run and how long they're kept. Then restore one into a test copy. A backup you've never restored is a hope, not a backup.
6Test and live are separate
Many prototypes run on one database with one set of keys, so the first time you test a change, you're testing it on your customers. You want a staging copy with its own database, its own keys and payments in test mode.
Money and messages
7Payments are confirmed by the payment provider, not the browser
A "payment successful" screen proves nothing on its own. An order should only be marked as paid when your server receives a webhook from Stripe (or your provider) and verifies its signature.
While you're there, check what happens with a failed payment, a refund, and the same webhook arriving twice. All three happen in real life.
8Emails actually arrive
Sign-up confirmations and password resets that land in spam are silent failures: users just leave. Send from your own domain through a transactional email service, set up the SPF, DKIM and DMARC records it asks for, and test with both a Gmail and an Outlook address.
Running it
9You own the accounts, and deploys are repeatable
Hosting, domain, database, email and payment accounts should be in your company's name. Releasing a change should be one repeatable step, not someone clicking around a dashboard from memory.
10You hear about errors before your users do
Add error tracking, such as Sentry, and an uptime check. When something breaks, you should get an alert with enough detail to fix it, not an email from an annoyed customer.
11There are limits on abuse and AI spend
Public forms and AI features attract bots. Add rate limits to sign-up, login and anything that calls an AI model, and set a monthly spending limit with your AI provider. One script hammering your chatbot can burn a month's budget overnight.
12Someone else could change it safely
Could a new developer get the project running from its README? Are the settings and environment variables written down? Are there at least a few tests on the paths that matter: sign-up, payment and your core feature?
If the only thing that understands your app is the AI tool that wrote it, every change is a gamble.
How did you do?
If all twelve are covered, launch with confidence. If three or more are open, or you're not sure how to check them, that's normal for an AI-built app and it's usually fixable without starting over. Often the product itself is fine; it's the production layer underneath that's missing.
Want us to check yours? Our 48-hour health check goes through all twelve points on your code and gives you a written report in order of risk: what to keep, what to fix and what to rebuild, with a fixed quote for getting it live.