I fix apps for a living, and most of my rescue work now starts the same way: an app that looks finished, built fast with AI tools or no-code, about to take real money from real users. The founder wants to know one thing. Is it safe to launch?
Here are the six checks I run on every one, and what they usually find.
1. Can one user see another user's data?
The number one finding, by a mile. Auth "works": people sign up, log in, see their dashboard. But underneath there are no privacy rules or row-level security policies, which means any user with the network tab open can pull everyone's records. You never catch this in testing because in testing you are the only user.
On Supabase-backed apps (including everything Lovable builds), the check is whether RLS is enabled and correct on every table, not just the obvious ones. On Bubble it's privacy rules. On custom code it's every endpoint. Most apps I review fail on at least one table.
2. What happens when a payment fails?
The happy path is always wired: card in, money through, access granted. Then a card declines, a subscription cancels, a webhook doesn't arrive, and nothing is listening. People keep paid access free, or paying customers get locked out, and you learn about it from an angry email.
The check: fire every Stripe event your app should handle, including the ugly ones, and watch what happens. Silence is a failing grade.
3. Can pricing be manipulated?
If the price, the plan, or the "is this user premium" flag is decided anywhere the browser can touch, someone will change it. This takes ten minutes to check and I find it more often than anyone would like to believe.
4. What does an attacker see in your API responses?
Apps routinely return whole database rows when the interface needed three fields. Email addresses, internal notes, other users' IDs, sometimes password hashes, all sitting in responses nobody ever looked at. The interface hides it. The network tab doesn't.
5. What breaks at 500 real users?
Flat tables, unindexed searches, workflows that fire twice, N+1 queries: none of it hurts with 10 test records. The first busy day is the worst possible time to find out. A read of the schema and the heaviest queries predicts almost all of it in advance.
6. When something fails, does anyone find out?
No error handling means failures are invisible: a white screen, a button that does nothing, an order that vanishes. Users don't report it, they leave. The check is simple: break things on purpose and see whether the app tells the user anything, and whether it tells you anything. Logging that nobody reads counts as no logging.
The pattern behind all six
Every one of these looks fine from the founder's chair, because from the founder's chair you're one trusted user on an empty app. The flaws only activate when strangers and money arrive, which is precisely the moment you can least afford them.
AI builders and no-code get you to 80% at a speed that still amazes me. The last 20%, the part where a prototype becomes a product someone can safely pay for, is a different kind of work.
If you're planning to charge real money, get technical eyes on it before launch, whether that's us or anyone competent. A written report with every issue ranked and its fix spelled out costs a fraction of what the first public data leak does.
