QUAICU
A vibe-coded app is ready for production when it keeps strangers out of your users’ data, keeps secret keys out of the browser, can be restored after a bad day, and changes in a way you can see and undo. Most AI-built apps work in a demo long before they meet those four tests. This checklist gives you twelve concrete things to check, written for founders who did not write the code line by line.
You do not need to be an engineer to run most of it. Where a check needs one, we say so.
Why does AI-built code need a separate check?
AI coding tools are very good at making things work and much less reliable at making them safe. When Veracode asked more than 100 language models to complete 80 coding tasks, 45% of the test cases introduced a vulnerability from the OWASP Top 10 list of common web security flaws (Veracode, 2025). Those were curated tasks, not production apps, but the direction is clear.
A separate review of 470 open-source pull requests by CodeRabbit found AI-written changes averaged 10.83 issues each, against 6.45 for human-written ones, roughly 1.7 times as many (The Register, 2025).
None of this means you should stop using the tools. It means someone has to check what they produce before customers rely on it. That is the gap we describe on our AI-built apps page.
Security: who can see what?
1. Can a logged-out stranger read your data?
Open your app in a private browser window, without logging in, and try the pages and links your users see. Then ask an engineer to call your database API directly with the public key that ships in your website. If anything comes back that belongs to a user, you have a problem.
This is the most common serious flaw we see in AI-built apps, and it is not hypothetical. In a May 2025 sample of 1,645 Lovable-built apps, 170 let anyone access personal information (The Next Web, 2026). If your app uses Supabase, read our guide to Supabase row level security in AI-built apps.
2. Can one logged-in user read another user’s data?
Create two test accounts. Log in as the first, note the address of a page that shows that user’s own record, then log in as the second and paste the same address. Try changing any ID you can see in the address bar. A safe app refuses. An unsafe one shows you someone else’s invoice, profile or messages.
3. Are any secret keys visible in the browser?
Open your live site, right-click, choose “View page source”, and search for words like secret, sk_, service_role and api_key. Anything that lets someone charge cards, send email or bypass your database rules must never be there. Tools such as Vite and Next.js deliberately bundle variables with certain prefixes into the code sent to every visitor, which is how many keys leak (Vite docs; Next.js docs). Our post on exposed secrets in AI-built apps walks through what to look for and what to do if you find one.
4. Are secrets kept out of your code history?
A key deleted from today’s code can still sit in an old commit. GitGuardian counted 23.8 million secrets leaked on public GitHub in 2024, and found that 70% of secrets leaked in 2022 were still active (GitGuardian, 2025). If a key was ever committed, assume it is known and rotate it.
Data: what happens when something goes wrong?
5. Do you have backups, and have you restored one?
Check what your hosting plan actually backs up. On Supabase, for example, daily backups are automatic on paid plans, while free-plan projects are told to export their data themselves, and database backups do not include files stored through the Storage API (Supabase docs). A backup you have never restored is a hope, not a plan. Our guide to backup and restore testing for small apps shows how to run a first test in an afternoon.
6. Are development and production separate?
If you test new features against the same database your customers use, one bad instruction can wipe it. In July 2025 a Replit AI agent deleted a live production database during a declared code freeze, and Replit then announced automatic separation of development and production databases (Fortune, 2025). Make sure your AI tool, and anyone experimenting, works on a copy.
7. Do you know what personal data you hold?
Write a one-page list: what personal data you collect, where it is stored, who can see it, and how long you keep it. If you serve users in India, the Digital Personal Data Protection Act and its 2025 Rules bring duties on notice, security safeguards and breach reporting, with most operational duties starting in May 2027 (AMS Shardul, 2025). You cannot meet them without knowing what you hold.
Operations: can you see and undo changes?
8. Does someone review changes before they go live?
AI tools can change dozens of files in one go. Somebody who understands the code should read each change before it reaches users, with special attention to anything touching login, payments or data access. “It worked when I clicked through it” is not a review.
9. Can you roll back a bad release in minutes?
Find out now how you would return to yesterday’s version if today’s breaks checkout. On most platforms this is a button or a single command. Write it down and try it once while nothing is on fire.
10. Will you know when the app is down or throwing errors?
Set up a free uptime monitor that checks your main page every few minutes and alerts you by email or chat. Add error tracking so you hear about crashes from a dashboard rather than from an angry customer.
11. Are payments and webhooks verified?
If you take payments, your server should confirm each payment with the payment provider and check the signature on incoming webhooks. An app that trusts whatever the browser says about a payment can be tricked into granting paid access for free.
12. Is there a record of who changed what?
Keep your code in version control, use separate accounts rather than one shared login, and turn on the audit logs your hosting and database providers offer. When something goes wrong, the first question is always “what changed?” You want an answer in minutes.
How do you prioritise if you can’t do all twelve this week?
Start with checks 1, 2 and 3. They cover the failures that expose other people’s data, which is the kind of mistake that is hardest to recover from. Then do 5 and 6, because they decide whether a bad day is an inconvenience or the end of the product. The rest can follow over the next few weeks.
If you find a problem, do not panic and do not ask the AI tool to “fix security” in one prompt. Make a list, fix the most serious item first, and have someone check each fix.
Where to get help
If you would rather have specialists run this for you, our free production check covers security, backups and environments, code and maintainability, and privacy. You get a walkthrough call, a written report and a quote, and a named engineer reviews every change we make after that. Learn more about how we work with AI-built apps.
Sources
- Veracode, AI-generated code security research press release (2025)
- The Register, CodeRabbit analysis of AI-written pull requests (17 Dec 2025)
- The Next Web, Lovable vibe-coding security issues (2026)
- Vite, Env variables and modes
- Next.js, Environment variables guide
- GitGuardian, The State of Secrets Sprawl 2025
- Supabase, Database backups
- Fortune, Replit AI agent deletes production database (23 Jul 2025)
- AMS Shardul, Enforcement of the DPDP Act and notification of the DPDP Rules