Lovable is brilliant at getting you from a prompt to a working React + Supabase app in an afternoon. The catch: the things that make it fast — a generated backend and a live preview that only ever runs as you — also hide the issues that matter once real users show up. Here are the mistakes we see most when a Lovable app goes live, and how to check for each before you flip the switch.
The database ships open
Lovable wires up Supabase quickly, and generated or AI-suggested row-level-security policies often end up permissive — using (true), or RLS left off entirely — so the app “just works” in preview. That same policy lets anyone with your public anon key (which ships in the frontend by design) read, and often write, every row in the table.
Check: In Supabase → Database → Policies, read every policy. A table with RLS off, or a policy of USING (true), is effectively public. You want each scoped to auth.uid().
Auth that only exists in the UI
Generated apps love to gate pages by hiding components — not logged in, the page doesn’t render. But the underlying Supabase queries are still reachable with the anon key. The real lock is row-level security, not the screen.
Check: Can the data be read by calling Supabase directly, ignoring your UI entirely? If yes, the UI “gate” is cosmetic.
More than the anon key in the client
While iterating it’s easy to end up with a service_role key or another secret pasted into client-side code. The anon key is meant to be public; the service-role key bypasses RLS completely — so it’s game over if it leaks.
Check: Search the generated client and built bundle for service_role or any key beyond the public anon key.
”The preview works, so it’s done”
Lovable’s live preview only ever exercises the happy path, as you, the owner. It never tries a second user, a hostile input, or a privileged page without a session — which is exactly where the bugs live.
Check: Have you tested as a different, non-owner user, on a fresh account?
Unvalidated writes from generated forms
Generated forms may insert straight to the database with no server-side validation or ownership check, letting a user write rows that aren’t theirs.
Check: Do writes validate input and confirm the row belongs to the acting user?
Before you go live
- Every table: RLS on, policies scoped to the user, on read and write.
- No key beyond the public anon key anywhere in the frontend.
- Tested as a second, non-owner user.
- Storage buckets private unless they’re genuinely public.