AI app builders make it possible to go from an idea to a working product in days. What they have not changed is what production demands. An app that looks finished can still let any visitor read your users' data, or let anyone run up your bill on a paid API. These are the problems we look for first in any app about to meet real users, and they matter most when an AI tool wrote code that nobody has read end to end.
Why fast builds need this list
AI tools generate code that works for the case you described. Security problems live in the cases nobody described: the visitor who is not logged in, the user who edits a request by hand, the key that ended up in the browser. In May 2025 a security researcher disclosed CVE-2025-48757, which described Lovable-generated projects whose data could be queried directly because row-level access rules were missing or too weak. Lovable now documents built-in security scans, and its own documentation says they do not replace a thorough security review.
Access rules on every table
Many AI-built apps use Supabase, where the browser talks to the database directly with a public key. That design is safe only when row-level security is enabled and the policies are right. Supabase's documentation is direct about it: a table in an exposed schema without row-level security can be read and written by any role that has access to it, so row-level security should be enabled on every table in an exposed schema.
Test the rules as someone else
Rules that work for the person who wrote them are still untested. Log in as a second user and try to open the first user's records. Log out and try again. Do it for reading, creating, changing and deleting. If any of those succeed where they should fail, you found the problem before a stranger did.
Keep secret keys on the server
Anything the browser downloads can be read by anyone who visits. Public keys are designed for that. Secret keys, such as a database service key or a payment provider's secret key, belong on the server only. Supabase's documentation says never to use a secret key in the browser, because it bypasses row-level security entirely. Search the files your app actually serves for anything that looks like a key, as well as the source you see in the editor.
Check every action on the server
Hiding a button only changes what honest users see. If a request to change a price, approve an order or delete an account can be sent at all, the server has to check who is sending it. Quickly built apps often put these checks only in the interface, where anyone can skip them.
Protect the money paths
If the app takes payments, the webhook your payment provider sends must be verified with its signing secret before the app acts on it. Otherwise anyone can tell your app that an invoice was paid. Stripe documents this verification step for its webhooks. And every paid API the app calls for a user, from AI models to maps, needs a per-user limit, so one person or one script cannot spend a month's budget in an afternoon.
The unglamorous part
A backup you have never restored is a hope rather than a plan. Restore one before launch and time how long it takes. Then make sure errors land somewhere a person will see them, with enough context to fix them. None of this is specific to AI-built apps. It is simply the part of launching that a prompt rarely asks for.
The full pre-launch checklist we run
Is your Lovable app ready for paying users?
If you built your product with an AI tool and want a second pair of eyes before launch, bring it to a 30-minute intro call with Alexandru. We will tell you plainly what we would check first.