Is your AI-built app safe to rely on? A 20-question checklist
Your team, or you, built an app with Lovable, Bolt, Cursor, Replit or another AI coding tool, and it works on the screen. This checklist is for the day before real customers, real orders or real money depend on it. Twenty yes/no questions, no jargon needed to answer most of them. Every "no" is a conversation to have, not a verdict.
First, which of three levels is your app?
The same checklist does not weigh the same for every app. Place yours first.
Level 1: a read-only tool
It shows information and changes nothing: a dashboard over a spreadsheet, an internal lookup page. If it breaks, someone opens the spreadsheet instead. The main risk is who can see it. Most of the "data and money leaks" group is enough.
Level 2: a system of record
It is where the truth lives: a booking app that holds every appointment, a customer list, a stock count. If it loses or mixes up data, nobody has another copy to fall back on. Work through all four groups before you add more users.
Level 3: an app that acts
It sends, orders or pays on its own: an invoice sender that emails customers, a Shopify order sync that creates orders in another system, an agent that can change records. A mistake does not stay inside the app, it reaches other people. All four groups, including the last one, and a review before more users.
Levels 2 and 3 need a review before you add users, because the cost of a flaw grows with every user and every record: a leak affects everyone in the database, a bad sync repeats on every order, and a mistake that reaches a customer cannot be unsent.
The checklist
Answer yes or no. If you do not know, that is a no until someone checks.
Group 1. Data and money leaks
1. Are all secrets (API keys, database passwords, payment keys) kept out of the code and out of the browser?
Example: the key that lets the invoice sender email customers must not be readable by opening the page source. If a key was ever pasted into the chat with the AI tool or committed to a repository, treat it as exposed and replace it.
2. Can customer A never see customer B's data, including by changing an ID in the web address?
Example: in the booking app you open /booking/1042. Change it to 1043. If you see someone else's booking, the rule that keeps customers apart is missing. Try it logged in as two different test customers.
3. Are admin pages and admin actions locked on the server, not just hidden from the menu?
A button that is not shown is not a lock. Open an admin address while logged in as an ordinary user and see what happens.
4. Have former staff, freelancers and old test accounts lost their access everywhere?
Everywhere means the hosting account, the database, the code repository, the AI tool workspace and the payment dashboard.
5. Does the app collect and keep only the data it needs?
Data you never stored cannot leak. If the booking form asks for a date of birth that nothing uses, remove the field and delete what was collected.
Group 2. Does it really work?
6. Has someone who did not build it created a brand-new account and completed the main task end to end?
Sign up, confirm the email, do the thing, receive the result. The person who built it always has a special account that skips the hard parts.
7. Does the data survive a page refresh and a restart of the app?
If the booking disappears after a refresh, or the app forgets everything when it is redeployed, it is keeping data in a place that is not permanent.
8. When the network drops mid-action, does the app say so instead of showing "success"?
Example: the Shopify order sync loses its connection halfway. The app should report failure and retry or alert, not silently skip the order.
9. Does a double click, or a second tab, create exactly one record?
Click "Pay" or "Send invoice" twice, fast. One invoice, one charge, one email is the only acceptable answer.
10. Does it refuse bad input: a typo in an email, a negative amount, a date in the past?
Try the silly things on purpose, in every form. The server must refuse them, not only the form on screen.
11. Does it still behave when two people use it at the same moment?
Example: two customers book the last free slot at the same second. Exactly one should get it.
Group 3. Can someone else run it?
12. Is there a written description of how to set it up from nothing?
One page is enough: where it runs, which accounts it needs, which settings must exist. If only one person knows, the app has a single point of failure.
13. Are changes tried on a copy before they reach the live app?
A separate test version with test data. An AI tool that edits the live app directly can break it on a Friday evening.
14. Do alerts reach a named person when something fails?
Not "the logs exist" but "Maria gets a message when the invoice sender fails". Silent failures are the usual way these apps hurt customers.
15. Has a backup actually been restored at least once?
A backup you have never restored is a hope, not a backup. Restore it to a copy and open the result.
16. Can you see who changed what, and when, in the data and in the code?
An audit trail answers the question every incident starts with: how did this record end up like this?
Group 4. If it acts on its own
17. Does a human approve big or unusual actions before they happen?
Example: an invoice above a set amount, or a refund, waits for a person. Routine small actions can run alone.
18. Are there hard caps on what it can do in a day, such as emails sent, orders created or money moved?
A cap turns a runaway loop from a disaster into an annoyance. Set it in the system, not in a prompt.
19. Is there an off switch that one named person can use in under a minute?
Pausing the sync or the sender should not need the original builder, a deploy or a long search for a password.
How to read your answers
Count the "no" and "do not know" answers that apply to your level. For a level 1 tool, a few in group 1 are the ones that matter. For level 2 or 3, any "no" in group 1 should be fixed before you add users, and any "no" in groups 2 to 4 should have an owner and a date. The checklist is a screening tool: it tells you where to look, and it cannot prove the app is safe.
Why these questions: public incidents
Each item below was checked against the source linked. We left out figures we could not read on a primary source.
Missing database access rules in Lovable-generated projects (CVE-2025-48757)
The U.S. National Vulnerability Database describes "an insufficient database Row-Level Security policy in Lovable through 2025-04-15" that allows remote unauthenticated attackers to read or write arbitrary database tables of generated sites. The record also notes that the supplier disputes this, because each customer of the platform is responsible for protecting its own application's data. The researcher's disclosure says apps call the database directly with a public key, so missing or weak row-level rules can expose personal data, third-party keys and payment-related records. This is the failure behind question 2.
An AI agent deleted a production database during a code freeze (Replit, July 2025)
In July 2025 SaaStr founder Jason Lemkin reported that Replit's AI agent deleted a live database during a code freeze he had put in place. Replit's CEO, Amjad Masad, called it "unacceptable and should never be possible" and said automatic separation between development and production databases was being rolled out. Replit's own announcement of separate development and production databases is dated 21 July 2025. Reports differ on some details, so we cite no counts. The lesson sits behind questions 17 to 20: keep a test copy, keep restorable backups, and give an agent no more power than a person would be allowed to have unchecked.
Security testing of AI-generated code (Veracode, 2025)
Veracode's 2025 GenAI Code Security Report, October 2025 update, tested code from over 100 large language models across Java, JavaScript, Python and C#, and reports that the AI-generated code introduced risky security flaws in 45% of tests. It is a study of generated code, not of finished apps, and it says nothing about your app in particular. It is a reason to check, not a reason to panic.
Too many "no" answers? Here is what we do
Our AI App Rescue is a fixed-price diagnosis of an app built with AI coding tools: a written report with what is broken, why, how serious it is, and a fixed price for each fix. Code comes to us through GitHub, never your builder login. We make no promise about traffic, revenue or that every bug is found, and the report says exactly what we checked.
See AI App RescueFrequently asked questions
Does a "yes" to all 20 questions mean my app is safe?
No. The checklist is a screening tool for the most common gaps in apps built quickly with AI coding tools. It cannot find a flaw nobody thought to ask about. A full review reads the code and the settings.
I am not technical. Can I still use it?
Yes for most of it. Questions 2, 6, 9 and 10 can be tested by clicking. For the others, hand the list to whoever built the app and ask for a yes or no with a short proof for each.
What should I fix first?
Anything in group 1. A leak of customer data or a key cannot be undone, while most other gaps can be fixed in time. After that, the items in groups 2 to 4 that match your level.
Is an AI-built app worse than a hand-written one?
Not by nature. AI coding tools are fast at getting something working, and speed tends to skip permissions, error handling, tests and backups. The same checklist applies to any app that went live quickly.
Why is this checklist free?
Because most apps need these checks whoever does them. If you want a second pair of eyes, the AI App Rescue diagnosis is a separate, paid, fixed-price service, and you are under no obligation.
Do you need a call to review my app?
No. We work in writing and through GitHub, with a written report at the end.