ZenLoaf / Guides
Is your AI-built app safe to launch? 7 checks before real users arrive
Not until seven things are checked. Apps built with Lovable, Bolt, Cursor or Replit tend to break in the same places once real people sign up and pay: who can read the data, who can act as an admin, where prices are set, where secret keys live, how payments are confirmed, what happens when something fails, and how the app holds up, and what it costs, as it grows. Each check below starts with something you can test yourself today.
- Who can read the data
- Who can act as an admin
- Where prices are set
- Where the secret keys are
- Payments, webhooks and the awkward cases
- Errors, backups and limits
- Will it hold as you grow, and at what cost
1. Who can read the data
The most common serious gap. If your app uses Supabase, the key in your app's code is meant to be public. What keeps one user out of another user's records is row-level security (RLS): rules in the database for every table.
How to check
- Sign up as two test users. As user B, open a page that belongs to user A, for example by changing the ID in the address bar. You should see nothing.
- In the Supabase dashboard, open each table that holds user data and confirm RLS is on and there is a policy for reading, adding, changing and deleting.
- Look for policies written as
using (true). That lets everyone in. Enabled is not the same as correct.
2. Who can act as an admin
AI tools often hide admin buttons instead of protecting admin actions. Hidden isn't protected.
How to check
- Signed in as a normal user, visit your admin pages directly by typing their address.
- Check where a user's role is stored. If it sits in a profile row the user can edit, they can make themselves an admin.
- Admin checks have to happen in the database or on the server, not only in the page.
3. Where prices are set
If the browser tells your checkout what to charge, someone can change it. A $90 class becomes a $1 class.
How to check
- Find the code that starts checkout. The amount should come from your server or from a fixed Stripe price, never from the page.
- With Stripe Checkout, pass a price ID created in Stripe, not an amount.
4. Where the secret keys are
Some keys are meant to be public, like the Supabase anon key and the Stripe publishable key. Others must never reach the browser: the Stripe secret key, the Supabase service_role key, and AI provider keys.
How to check
- Open your live site, open the browser's developer tools, and search the loaded files for
sk_andservice_role. - Search your code history too. Deleting a key from the latest version doesn't remove it from older ones.
- If a secret key was ever public, replace it today, then move it to the server.
5. Payments, webhooks and the awkward cases
The happy path usually works because you tested it as yourself. The other paths are where money and trust go missing.
How to check
- Check that your Stripe webhook verifies Stripe's signature, so nobody can fake a "payment succeeded" message.
- Use Stripe's test cards to try a declined payment, a cancelled subscription and a plan change.
- Try signing up twice with the same email, resetting a password, and using an expired verification link.
6. Errors, backups and limits
If nothing reports errors, the first you'll hear of a crash is from a customer.
How to check
- Set up error tracking so crashes reach you before customers do.
- Find out whether your database is backed up on your plan, and restore a backup once to prove it works.
- Put limits on sign-in attempts and on anything that calls an AI model, and set a spending cap with your AI provider.
7. Will it hold as you grow, and at what cost
AI-built apps often feel fast with ten users and slow at a few hundred, and the bill grows faster than the user count.
How to check speed
- Open the browser's network tab and load your busiest page. Dozens of small database requests usually means queries inside loops.
- Look for lists that load every record at once. They need pagination before your data grows.
- Check which columns you filter and sort by. Large tables need indexes on them.
How to keep costs down
- AI calls: cache answers you've already generated, use a smaller model where it's good enough, and cap usage per user.
- Database: load only the fields and rows each page needs, and stop repeated requests for the same data.
- Storage: resize images before storing them and clean up files nobody uses.
- Your plan: know the limits of your Supabase and hosting plans, and what the next tier costs, before a launch pushes you over.
One more: when the AI says it's fixed
After any fix, run the test again as a real user. Don't ask the AI whether it worked. Ask the app.
When to get help
If one of these checks fails and you're not sure how to fix it, or you already have paying users, a second pair of eyes is cheaper than a leak. Our launch audit runs all seven checks on your app in 3–5 days and gives you a written verdict: what to fix, what to leave alone, and what it will cost to grow.
Sources: Veracode, GenAI Code Security Report, July 2025 (code with a known security flaw in 45% of tasks across 100+ models); CVE-2025-48757, May 2025 (170 of 1,645 scanned apps on one AI app builder exposed user data).
Questions about launch checks
- Is the Supabase anon key a secret?
- No. The anon (public) key is meant to be in your app's code. What protects your data is row-level security: rules in the database that decide which rows each user can read and change. The service_role key is different. It bypasses those rules and must never be in the browser.
- What is row-level security?
- Row-level security (RLS) is a database feature, used by Supabase, that checks every read and write against rules you write, such as 'users can only see their own bookings'. Turning it on without rules blocks everything; turning it on with a rule like 'true' allows everything. The rules have to match what each user should see.
- Is a built-in security scan enough?
- It's a good start. Scanners catch common configuration mistakes, but they can't tell whether your rules match what your users should be able to see, or whether a fix the AI made actually works. Test as a real user too, with two separate accounts.
- How long do these checks take?
- Running the tests yourself takes an afternoon. Fixing what they find depends on the app: some fixes take minutes, others need a developer.
- How do I keep my app's running costs down as it grows?
- Most of the bill comes from AI calls, database reads and file storage. Cache answers instead of asking the AI again, use a smaller model where it's good enough, set limits per user, and load only the data each page needs.