The short version
- Your code was never the lock-in. It is a normal React + TypeScript app on Vite; it builds anywhere.
- The two real dependencies are Lovable Cloud and the AI Gateway — and they are separate. Escaping one does not escape the other.
- Security comes before migration. The documented failure mode of Lovable apps is not downtime — it is a database readable by strangers.
- Nobody can size your migration from the outside. Published estimates run from 4–6 hours to 2–3 months and both extremes are misleading. The honest number comes from counting what is in your repository.
What Lovable actually gives you
Under the editor, a Lovable project is a conventional stack: React 18 with TypeScript on
Vite, Tailwind and shadcn/ui for components, and Supabase behind it — Postgres, Auth,
Storage and Deno edge functions
(Lovable docs).
The GitHub integration is genuinely two-way: Lovable pushes commits, and commits you push
sync back into the editor
(docs).
Schema changes are written as real SQL migration files into
supabase/migrations/ in your repository, and edge functions are ordinary
TypeScript in supabase/functions/. The one Lovable-specific build plugin,
lovable-tagger, is MIT-licensed open source
(npm)
and simply gets deleted outside the editor.
This matters because most "escape Lovable" anxiety is aimed at the wrong thing. The code is portable. What binds you is infrastructure and plumbing, and there are exactly two pieces of it.
The two real dependencies
1 — Lovable Cloud
If your project uses Lovable Cloud, your Supabase project — database, auth, storage, edge runtime and all the data — is provisioned and managed by Lovable (docs). There is no one-click migration out. The documented path is: export project data, remove Lovable Cloud, connect your own Supabase project, and rebuild the schema there. The Cloud region is fixed permanently once chosen, and migrating back in is not supported.
If instead you connected your own Supabase project from the start — which is supported — the largest cost of leaving simply does not exist for you. Your data does not move. Establishing which of these two situations you are in is the single most important fact in sizing the whole job.
2 — The AI Gateway
If your app's AI features route through Lovable's AI Gateway, every call uses a Lovable-issued key. This dependency survives a database migration — it has to be unpicked separately, function by function, and repointed at your own provider key. If the feature runs a tool-calling loop, request and response shapes matter, so it is careful rewiring rather than a URL swap. Run a behavioural benchmark before and after; silent regressions in an AI feature are the kind nobody notices until a customer does.
Before any migration: the security pass
This is the part of the guide we would ask you to read even if you never hire anyone.
In 2025, a researcher disclosed CVE-2025-48757: Lovable-generated Supabase schemas shipping without Row Level Security enabled, or with policies that did not hold. The confirmed count was 170+ live applications and hundreds of endpoints where email addresses, messages, payment records and API keys were readable with nothing but the public anon key (Superblocks, TNW).
The detail that matters: the scanner Lovable shipped in response checks whether RLS is
present, not whether a policy is correct. A policy of
USING (true) is enabled, passes the scanner, shows green in the dashboard —
and returns every row in the table to anyone holding the anon key. "RLS is switched on"
is therefore not an answer to the security question. Reading each policy against the
roles it is meant to separate is the work, and nothing currently automates it.
Nor is this Lovable-specific carelessness. Veracode's 2025 study across 100+ models found AI-generated code chose the insecure implementation about 45% of the time, with no improvement in newer models (Veracode). AI-built apps deserve a security review for the same reason fast-built houses deserve a survey — speed and soundness are different properties.
The minimum pre-launch pass for any Lovable app:
- Every RLS policy read against the roles it separates — correctness, not presence. Supabase's own database advisors catch the crude cases (RLS disabled, enabled-but-no-policy); they do not judge whether a policy is right.
- Secrets scanned across the full git history, not the latest commit — a key committed early and "removed" later is still in the history and still live.
- Edge functions inventoried: which hold the service-role key, which skip JWT verification, which are dead.
- Storage bucket policies — the usual home of user documents — checked for public exposure.
- The two or three riskiest flows (sign-up and role assignment, anything involving money or moderation) traced end to end for authorisation gaps no scanner finds.
What a migration actually consists of
Assuming your Supabase project is your own, leaving Lovable means replacing the five things the platform quietly does for you:
- Frontend hosting and build. A static Vite bundle — any host works. This is the easy part, and it is the only part the "4–6 hour migration" articles actually cover.
- Edge function deployment. Lovable pushes these for you; they do not deploy on git push. You need CI that deploys them — sized by how many functions and shared modules you have.
- Database migrations from CI. Applied through the platform UI today, typically with no record of what ran and no rollback path. Moving this to CI is not just a replacement — it closes a gap you already have.
- Type regeneration from the schema after changes — a scripted step.
- The AI Gateway swap, if you use it — see above. Usually the largest single item, and the one most often missed in scoping.
Plus the housekeeping that decides whether the move is clean: where secrets live afterwards (they sit in the platform's settings UI today), auth callback URLs for the new domain, and removing the dev-time plugin.
How to size it honestly
We went looking for credible public data on Lovable migration effort and did not find any. The low figures describe frontend rehosting only. The high figures — "2–3 months", five-figure "rescue" pricing — come from agency marketing pages with no stated method, no case data and no way to check them. Treat any number produced without reading your repository as marketing, whoever says it. That includes us.
What produces a real number is counting, in your actual project:
- tables vs RLS policies (
pg_policies), and which policies are role-scoped vs permissive; - edge functions, their lines, external calls, and shared helper modules;
- AI gateway call sites and key references;
- whether the schema exists as versioned migration files or only as live database state — the difference between portable and reconstruct;
- test coverage as measured, not assumed;
- secrets found by a history-wide scanner such as gitleaks or trufflehog.
Those counts turn "somewhere between a week and three months" into a developer-day estimate whose arithmetic you can check yourself.
Keep or migrate — both are fine outcomes
Migrating is not automatically the right answer, and a firm that opens with "you must get off Lovable" is selling you their invoice. Staying keeps the editor for fast visual iteration and avoids the move entirely — at the price of the testing ceiling, a margin on every AI call, and platform risk. Leaving costs a bounded block of work once — and buys CI, staging, rollback, direct provider pricing and proper testing. The right way to decide is to price both against the same evidence and keep the decision record, whichever way it goes.
If you want help
Appaya does this as a fixed-fee review: the security pass above, run policy by policy against your actual repository and Supabase project, plus a migration estimate in developer-days with the counts it is derived from — so you can check the arithmetic rather than take our word for it. If the review finds your app is fine where it is, that is what the report says.