A Lovable app that works eventually reaches a turning point. People use it every week, and some of them pay for it. Then the requests change. The next prompt is no longer "add a dashboard". It is "make sure no customer can ever read another customer's invoices", or "our biggest prospect needs us to pass a security review". That is where a prototype tool and a production codebase start to want different things.
What Lovable Actually Gives You
It is worth being precise, because Lovable is not a toy. It describes itself as a full-stack AI development platform, and the output is real code. Projects created since May 13, 2026 run on TanStack Start with server-side rendering and publish as an edge Worker. Older projects are React and Vite apps that render in the browser. Either way, the frontend is React.
The backend is real too. Data lives in PostgreSQL, either through Lovable Cloud, which is built on Supabase's open-source foundation, or through your own Supabase project. You get authentication, file storage, serverless edge functions and a secrets store. On a Supabase-backed project, each approved schema change is saved as a migration file under supabase/migrations/. Every publish runs a quick security scan that flags tables without row-level security and audits npm dependencies, and a deeper code scan is available on demand. On new projects, variables with a VITE_ prefix go to the browser, and everything else stays on the server.
You also own the result. Lovable's FAQ is plain about it: your apps, code and content are yours, and you can host them wherever you choose. Git sync keeps a two-way copy in GitHub, GitLab or Bitbucket on any plan, and paid plans can download the whole codebase. For validating an idea, that is a strong set of tools. The real question is whether the way the code gets made still fits your stage.
What Starts to Strain as Real Users Arrive
None of what follows is a bug in Lovable. It is what happens when a codebase built through conversation meets the demands of a growing business.
Security becomes a review, not a scan. Lovable's own guidance says frontend code "should never make security decisions" and that authorization belongs in server-side code. It also says its scanners "cannot guarantee complete security" and do not replace a thorough review for apps that handle sensitive data. AI-generated prototype code often keeps some permission checks in the browser and adds access policies one prompt at a time. Each policy can look correct on its own. Together, they are hard to reason about without a test that proves user A cannot read user B's rows.
The team outgrows one branch. Lovable edits and syncs one branch at a time. If the repository and Lovable both have commits the other lacks, Lovable pushes to a lovable-sync branch for you to merge by hand. That works well for a founder and an AI agent. It gets harder when two engineers work in parallel, each pull request needs review, and CI must pass before anything ships.
Building and serving share one balance. Lovable uses a single credit balance for building, hosting and the backend. Cloud usage is measured by the hosting and backend resources your deployed app consumes, and apps that use Cloud or AI features need available credits to serve requests. For a prototype, one balance is simple. A business usually wants the cost of serving customers on its own bill, with its own alerts and limits.
The exit gets longer with every table. There is no one-click migration from Lovable Cloud to your own Supabase project. You export the data and rebuild the schema. That is a fair trade for a managed backend, but the work grows as the app grows.
Where Lovable Stops Being the Right Tool
Lovable's own hosting guidance says that, for most applications, hosting on Lovable is the most efficient option. It also names the exceptions: compliance or data residency mandates, networking such as VPC peering or private endpoints, and policies that require self-managed or audited hosting. We would add one more. When the main risk to your business moves from "can we build it?" to "can we change it safely?", the tooling should move with it. Lovable shortens the loop from idea to working screen. The next stage needs reviewed changes, tests in CI and infrastructure you can audit.
How We Migrate a Lovable App
We run the same 6-week migration for every platform, with a few steps that are specific to Lovable. We build the production app from the ground up, but the Lovable project is not thrown away. It is the most precise specification you have, and sound React components can often carry over.
- Handover and audit: You give us the repository through Git sync or a codebase download, plus a walkthrough of the app. We read the migrations, every row-level security policy, the edge functions and the list of secrets. Then we agree the exact 6-week scope with you.
- Schema and migrations: We compare the live database with its migration history, then define the schema in a migration tool in your repository, with explicit foreign keys, constraints and indexes.
- Business logic on the server: Pricing rules, permission checks and calls that use private keys move into a Node.js or Python API. Row-level security stays in PostgreSQL as a second layer, and we review each policy by hand.
- Auth, payments and data: We set up authentication and payments in the new stack. Custom scripts export your data and import it into PostgreSQL, and we rehearse the import on staging before launch.
- Tests and CI: An automated test suite covers your core flows and access rules. CI runs it on every pull request, so a change that leaks one customer's data to another fails before it merges.
- Secrets, observability and cost: Secrets live in your hosting provider's secret store. Any private key that was ever given a
VITE_prefix is treated as exposed and rotated. Structured logs and error tracking show what failed and for whom, and hosting goes on its own bill with alerts. - The harvest: You see weekly demos on a staging server during the sprint. At the end, we hand over your GitHub repository and deploy to your cloud, with 30 days of bug fixes included.
What Changes in the Migration
Schema as Code
Schema changes stop arriving one approved prompt at a time. Each change is a reviewed migration with explicit constraints, tested in CI.
Tested Access Rules
Access checks move out of the browser and into server code, backed by row-level security and tests that prove they hold.
Infrastructure You Own
Hosting stops drawing on the same credits as building. It runs in your own cloud account, with its own bill, logs and alerts.
Signs You Are Ready to Move
Not every Lovable app should migrate. If you are still testing whether people want the product, stay where you are. For that stage, prompting is faster than any agency.
The signals we look for are practical. A second engineer joins and needs branches, code review and CI. You hold payment, health or customer records, and a security questionnaire is on its way. A customer or regulator asks for data residency, private networking or audited hosting. Or a fix in one place breaks something in another, and nobody can say why without reading the whole codebase.
If two or more sound familiar, have an engineer look at the code before the next growth push.