Lovable
Take your Lovable app from working to production-ready.
Lovable gets an idea to a working app quickly, and most of the people using it are building a business, not a codebase. When real customers, payments or an investor arrive, the questions change: who can see which data, what the browser is trusted with, and what happens when something breaks.
In Lovable's own survey of 14,300 users, 4 in 5 are non-technical and 80% build solo. Lovable: The Build Economy
Common failure modes
These turn up in fast-built apps whatever they were built with, once an app grows faster than anyone reviews it. Most can be fixed where the app is.
-
Tables anyone can read
A Lovable app that uses Supabase sends a public key to every browser. That is by design: row-level security is what decides which rows each user can read or change. Without it, the public key opens the table.
Apps built with Lovable on Supabase have shipped with row-level security missing, recorded as CVE-2025-48757. Wikipedia: Lovable (company)
-
Access rules that exist but are wrong
Row-level security switched on is not the same as row-level security that is right. A policy can let any signed-in user read every row, or trust a user ID the browser sends. Checking that takes someone who knows who should see what.
-
Secrets in the browser
Keys for paid APIs, payment providers or email services belong on a server or in an edge function, never in code the browser downloads. Anything shipped to the browser can be read by anyone who opens the page.
Escape.tech scanned 5,600 deployed apps built by vibe coding and found more than 2,000 high-impact vulnerabilities, more than 400 exposed secrets and 175 instances of exposed personal data. Escape.tech
-
Rules that live only in the interface
A paywall, an admin screen or a usage limit enforced by hiding a button is not enforced. The same rule has to hold where the data is.
-
Changes without a safety net
A prompted change can fix one flow and quietly break another. Without tests on the flows that make money, or a staging copy to try changes on, production is where problems are found.
Veracode found that 45% of AI code-generation tasks introduced a vulnerability, and that security performance had 'remained unchanged over time' as models improved. Veracode, via BusinessWire
What the audit checks on a Lovable app
The code and product audit reads the code, not only what is visible from outside, and ranks every finding by what it means for the business. On a Lovable app, that includes:
- Every Supabase table and storage bucket: whether row-level security is on, and whether each policy matches who should see what.
- Authentication: sign-up, email verification, password reset, sessions and roles.
- Keys and secrets in the shipped JavaScript and in edge functions.
- The payment path, from checkout to the webhook that grants access.
- How changes reach production: the GitHub sync, environments, and what happens when a change goes wrong.
- Performance on the pages your users wait for.
- Your product and business goals, from an interview, so every finding is ranked by what it means for the business.
Production-ready where you are
The default recommendation is to make your app hold up where it is, on Lovable. Moving off is recommended only when the audit shows it is worth the cost.
Run the free check on your Lovable app.
It scans what your app already shows the world, such as keys in its JavaScript, its headers, HTTPS and versions, and Aaron reviews the result within two business days. It runs only after you confirm by email and show the app is yours.