Is a Lovable app production-ready out of the box?

No. It's a working prototype on a solid stack. Row-level security, auth URLs, edge-function secrets, migrations, storage policies and deploy all need to be done deliberately. Steps 3–5 above are launch-blocking.

Do I need to leave Lovable to go to production?

No. Keep it connected to GitHub and keep using it for new features. What changes is that the repo, with branches and review, becomes the source of truth so regeneration can't undo fixes.

Why can't Google see my Lovable site?

Lovable ships a client-rendered app; the initial HTML is empty. Pre-render or server-render public routes. Check with curl: the content should be in the HTML.

How do I test RLS properly?

Create two real accounts. Log in as one and try to read, update and delete the other's rows through the app and directly through the API. Every attempt should fail. Then check no policy uses USING (true).

What's the minimum before I let real users in?

Steps 3, 4 and 5: RLS with real policies, service-role key out of the client, auth configured on the real domain. Those three protect your users' data and access. Do the rest in the following weeks.

Vibe coding

Lovable to production: the complete checklist

Author

AI Cubed

Published

September 9, 2026

Read time

11 min

TL;DR

Fourteen steps, in order: confirm GitHub sync, run it locally, enable RLS with real policies on every table, get the service-role key out of the client, set auth URLs per environment, capture the schema as migrations, harden edge functions, lock storage buckets, add error handling, put tests on the money paths, deploy to a host you control, server-render public pages, add monitoring and backups, and put every account in your name.

Steps 3–5 (RLS, service-role key, auth URLs) are launch-blocking. Do them first.
Lovable's client-rendered output is invisible to search engines and AI crawlers until you pre-render or server-render public routes.
Keep Lovable connected afterwards — the repo, not the prompt, becomes the source of truth.
Most apps: two to four weeks with an experienced engineer.

Lovable's stack is consistent — React and Vite, Tailwind and shadcn/ui, Supabase for auth, Postgres, storage and Deno edge functions — which means the path to production is consistent too. This is the checklist, in the order that keeps your users safe while you work through it.

Each step says what to check and what "done" looks like. If you're not technical, hand this list to whoever you hire and ask them to tick it. If they push back on a step, ask why in writing.

The checklist, in order

Confirm the GitHub sync and clone the repo. Done when: you can see every commit Lovable made, locally.
Run it locally with the environment variables. Done when: the app runs on your machine, not just in Lovable's preview.
Enable RLS with real policies on every table. Done when: two real accounts cannot read each other's rows, and no policy says USING (true).
Get the service-role key out of the client. Done when: a search for service_role in anything the browser loads returns nothing, and the key has been rotated.
Set auth Site URL and redirect URLs per environment; update OAuth callbacks. Done when: magic link, OAuth and password reset work on the real domain on a phone.
Capture the schema as migrations and run them on deploy. Done when: a fresh database built from the migrations matches production.
Harden edge functions: secrets per environment, error responses, logging, timeouts. Done when: a failing upstream call returns a real error you can see in logs.
Lock storage buckets: private, signed URLs, policies, upload limits. Done when: an unauthenticated request for a file fails.
Add error boundaries, validation, empty and failure states. Done when: a bad input shows a message, not a blank screen.
Tests on sign-up, the core action and checkout, running in CI. Done when: a PR that breaks checkout fails CI.
Deploy from the repo to a host you control, with preview environments and rollback. Done when: you've rolled back once, on purpose.
Pre-render or server-render public pages. Done when: curl on a public URL returns the content in the HTML.
Monitoring and tested backups. Done when: you've restored a backup and been paged by a test alert.
Every account in your name, documented. Done when: you could lock out everyone else tonight.

Lovable-specific gotchas

Things that catch people on this stack
Gotcha	What happens	Fix
Regeneration overwrites fixes	A later prompt regenerates a component you'd already corrected.	Make fixes in the repo on a branch; use Lovable for new features, review its PRs.
Lovable Cloud vs your Supabase	The app runs on infrastructure you don't administer.	Migrate to a Supabase project in your organisation; move auth users and storage.
Email confirmation on by default	Users can't log in after sign-up in production because the confirm email points at the wrong URL.	Fix the Site URL and email templates; decide whether confirmation is required.
Public buckets	Uploads are world-readable because the demo needed to display them.	Private buckets with signed URLs.
SPA routing on the host	Deep links 404 on the host because there's no rewrite to index.html.	Add the SPA rewrite — or move to SSR, which also fixes SEO.

How long this takes

Steps 3–5 in the first two or three days. The rest over two to four weeks for a typical app, with an experienced engineer. Longer if the schema has drifted far or there's a lot of public content to server-render.

What AI Cubed does about this

We run this exact checklist on Lovable apps: audit in two business days, then the rescue. Our own site started as a Lovable project and now ships server-rendered — see finish my Lovable app.

Frequently asked questions

Sources

Row Level Security — Supabase Docs
Redirect URLs — Supabase Docs
Lovable documentation — Lovable

Start here

See where your operation is losing time.

Twenty minutes with an operator, not a salesperson. We'll name the one bottleneck costing you the most — and tell you whether it's worth fixing with software at all.

Book your free 20-minute consult→

20 minutes · video call · no preparation needed