Lovable to production
Lovable is the fastest way we know to turn an idea into a React app on Supabase. It is also where we see the most Row Level Security switched off. Here is what its output gets wrong in production, and what we do about it — without taking Lovable away from you.
Taking a Lovable app to production means fixing what Lovable's generator optimises past: Supabase tables with Row Level Security disabled or set to allow everything, edge functions that skip the auth check, secrets pasted into client code or VITE_ variables that end up in the bundle, and a single-page app with no server rendering, tests, deploy pipeline or error tracking. Gen2Prod works in the GitHub repo Lovable syncs to, so you keep prompting in Lovable afterwards; the audit is free and every fix is a fixed price from $290.
The list we find on most Lovable projects, in the order it matters. Each one links to the service that fixes it.
Lovable scaffolds tables quickly and secures them badly. We find RLS disabled, or enabled with a policy of `USING (true)`, on most projects — which means anyone with your public anon key can read and write every row. We write policies per table and prove each one with a test.
Fixed by Security hardeningGenerated Deno functions often have JWT verification off and never check who is calling. Anything that costs money — sending mail, calling OpenAI, charging a card — gets an auth check and a rate limit.
Fixed by Security hardeningA `VITE_` variable is bundled into the JavaScript your visitors download. Third-party keys move server-side, behind a function that checks the caller first.
Fixed by Security hardeningThe SPA fetches on mount, one table at a time, so a dashboard makes ten round trips before it paints. We batch, index, and move the heavy reads to the server or to a view.
Fixed by Database & queries`Index.tsx` at 1,400 lines, with fetching, state and markup interleaved. We split it into pieces small enough that Lovable itself stops breaking unrelated features when you prompt it.
Fixed by Refactor & cleanupDeploys happen by clicking Publish, with no preview environment, no test gate and no rollback. We add CI that runs the tests and a one-command deploy to your own host, with the Lovable sync left intact.
Fixed by Deploy & CI/CDA cleanup isn’t a rebuild. Lovable did real work, and most of it stays.
Nearly always one of three things: an environment variable that exists in the Lovable editor but not on the deployed site, a Supabase RLS policy that behaves differently for a real logged-in user than for the anon session the preview used, or an edge function that was never deployed to the production project. The free audit names which one it is.
Yes, and most clients do. We work by pull request in the GitHub repo Lovable syncs with, and we leave the project in smaller files with clearer boundaries — a shape Lovable edits more reliably than the flat structure it generates. We also leave a short README telling it, and any human developer, where things belong.
No. Lovable Cloud is a managed Supabase project, and Supabase is a perfectly good production database. What needs to change is the policies, indexes and functions inside it, not the host. If you do want your own Supabase project for billing or compliance reasons, we can migrate the schema, users and storage, but we'll tell you honestly whether it's worth it.
The audit is free and comes back within 48 hours with a price against each finding. A single fix — the RLS policies, say, or moving secrets server-side — starts at $290. Taking a typical Lovable app all the way, with security, performance, CI and monitoring, is quoted after the audit and usually lands well under the cost of a month of a freelancer.
Go deeper: Lovable to production: what to fix before you launch
Start with the free audit. In 48 hours you'll know what's broken, what each fix costs, and whether it's even worth doing — before you've spent a dollar.
Free audit, no card · Fixed price before we start · Your code stays yours