Lovable to Custom Code: When to Switch and How to Plan It

Keep building in Lovable while the work is screens, flows and features. Move to custom code when the limit becomes people, process or a workload the platform does not run. Going from Lovable to custom code is rarely all or nothing: most teams sync the code into a repository they own, keep prompting for the easy changes, and replace one piece at a time.

This guide is for founders with a working Lovable app and a growing list of changes, and for teams about to put a developer on one. It covers what the platform genuinely handles, the signals that you have outgrown it, the hybrid setup most teams settle on, and a migration order that avoids a rewrite. The mechanics of the export itself are in our guide to getting your code, data and backend out of Lovable.

Key takeaways

• Connect Git sync now and move hosting later. A repository you own costs nothing and is reversible. Changing where the app runs is neither.
• Lovable Cloud covers the backend most early products need: database, sign-in, storage, scheduled jobs, edge functions, logs and backups.
• The real triggers for moving are engineering process, compliance requirements and work the platform cannot run, not slow pages or a broken publish.
• Most teams end up hybrid: Lovable for the interface, a repository for review and deployment, custom services for the specialised parts.
• Move in stages (repository, front end, backend services, then retire the old project) and keep the previous setup running until each stage passes.

What Lovable handles well

More than most founders expect. Lovable hosts the app and includes a built-in backend, Cloud, with a database, authentication, storage, realtime updates, scheduled jobs, edge functions, secrets, logs and database backups, as set out in Lovable's Cloud documentation. You also choose the region your data sits in, from the Americas, Europe or Asia Pacific, and resize the database instance as traffic grows.

If your next ten changes are new screens, extra fields, a second user role or a tidier email template, prompting is still the quickest and cheapest route to them. Stay where you are.

Two habits pay off while you stay. Connect Git sync so the code exists somewhere you control, and read what the agent changed after anything that touches money or access. Code editing inside Lovable is available on paid plans, while the Free plan editor is read-only, according to the code editor documentation.

When should you move from Lovable to custom code?

When a named constraint blocks the next few months of work. "It feels like a toy" is not a constraint. The five below are.

Signals that justify a move

• A second person writing changes. Two people prompting one project overwrite each other's work. Branches, pull requests and a staging copy are the fix, and they live in a repository rather than in a chat panel.
• Nothing checks the app before it ships. Lovable can write and run tests with Vitest, React Testing Library and jsdom, but its frontend tests run only when requested, per its testing documentation. Continuous integration runs them on every change, whether or not anyone remembers to ask.
• Compliance requirements with names. Single sign-on and the security centre sit on the Business plan, while audit logs, directory sync and Git sync data residency are Enterprise features. If a customer's security review demands those and an Enterprise contract is not realistic, the platform is the blocker.
• Work the platform does not run. Edge functions and scheduled jobs cover most background tasks, and Lovable writes and deploys those functions for you rather than letting you add one by hand, per the edge functions documentation. A long-running worker, a retrying queue, a data pipeline or an iOS and Android store build is a different kind of job.
• The same area breaking repeatedly. When a prompt that fixes billing breaks onboarding for the second time, the codebase needs structure the agent is not imposing: clear boundaries, types and tests around the parts that handle money.

Symptoms that are not reasons to leave

Some problems look structural and turn out to be settings. A published app that behaves differently from the preview is usually an unpublished change, a domain pointing at the wrong place or live-mode payment keys, and our walkthrough of the nine gaps between preview and production clears those in an afternoon.

Slow pages are the other false signal. Over-fetching, missing database indexes and full-size images cause them, and the fix is identical in generated and handwritten code. Measure one slow screen before you treat speed as a reason to migrate.

Stay, hybrid or move: the three options compared

The middle column is a real option, and it is where most teams with one developer end up.

How do you move without a rewrite?

In stages, in this order, with the previous setup still running at each one. The sequence protects you more than the tooling does.

1. Put the code in a repository you own. Install the Git integration on the company's GitHub organisation rather than a personal or contractor account. Leave Lovable on main and give developers their own branches.
2. Add a check that runs on every change. A short pipeline that installs dependencies and runs the tests on each pull request catches most of the regressions that prompting introduces.
3. Move the front end first. Deploy the repository to your own host on a temporary URL and verify three things against the live app: a nested route after a refresh, sign-in and sign-out, and a real write with a file upload. Point the custom domain at it only then, and leave the backend on Cloud throughout.
4. Replace backend pieces one at a time. Move the workload that forced the decision, such as the queue, the report builder or the integration, into its own service behind a documented API. Everything else stays until it earns a move.
5. Retire the old project last. Keep the Lovable project alive until real users have signed in, paid and uploaded files on the new deployment.

The check in step two is nine lines of configuration:

name: CI
on: pull_request
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

What becomes your job on day one

Deployment, TLS certificates and DNS, database backups with a tested restore, monitoring and alerts, access-rule maintenance, and the provider accounts behind sign-in, email and model calls. None of it is hard. All of it is somebody's Tuesday, so decide whose before you switch.

What does each option cost?

Lovable's published prices are the simple half: Free, Pro at $25 a month with 100 monthly credits, Business at $50 a month, and Enterprise on request, all listed on Lovable's pricing page. One balance pays for building and for the published app's own usage, which makes re-prompting the same bug the expensive habit. Our breakdown of where build and run credits actually go has the arithmetic.

Custom code swaps that subscription for engineering time plus hosting, which is larger in month one and better value per change once a developer is involved anyway. The number worth comparing is cost per shipped change rather than the monthly line item. If a change takes ten prompts and two reverts, and a developer would ship it in an hour, the platform has stopped being the cheap option for that kind of work.

Common mistakes when moving off Lovable

• Rewriting instead of migrating. The screens and flows customers already use are the asset. Replace foundations and keep the product.
• Moving the backend first. It is the hardest step and rarely the urgent one. Front-end hosting is reversible in an hour; a half-finished database move is not.
• Deleting the Lovable project as soon as the new deployment loads. Working means real sign-ins, a real payment and a real upload, not a page that renders.
• Leaving the repository in a contractor's personal account. Owning the code is the point of the exercise.
• Treating "we hired a developer" as the decision. A developer can work inside the Lovable project from day one. Whether to leave is a separate question with different evidence.

Frequently asked questions

Can a developer work on a Lovable project without leaving it?

Yes. Paid plans allow manual edits in Lovable's own code editor, and every save becomes a version you can revert. Lovable does not review those manual edits, so for anything beyond a small tweak, connect the repository and let the developer work in their usual editor with a pull request.

Will custom code make the app faster?

Not on its own. Most slow screens come from fetching too much data, missing indexes or oversized images, and those are fixed the same way wherever the code was written. Profile one page first, because if the answer is a query, migrating will not change it.

Do the AI features stop working if we leave?

The generated code keeps running, but anything that routes through Lovable's own services stops with the subscription, so model calls need your own provider account and keys. Arrange that before the project is switched off rather than after.

Can we come back to Lovable later?

Partly. The Git integration exports to a repository rather than importing from one, so a codebase that engineers have reshaped does not flow back into the project. Keep the Lovable project alive while you are still deciding, and treat the move as one-way once real work happens in the repository.

How do we decide this week?

List the next ten changes the product needs and mark each one as "a prompt could do this" or "this needs an engineer". If eight are prompts, stay and connect Git sync today. If five need an engineer, start the staged move, and run the exercise again next quarter.

Deciding without redoing the work

Lovable is a good place to keep building for longer than most people assume, and a poor place to be on the day a compliance review, a second engineer or a background worker arrives. Connect a repository now so the decision stays cheap, then move in stages and let each stage prove itself with real users before the next one starts.

If you would rather have senior engineers make that call with you and run the migration, AlgoSmiths works on fixed-price projects with a working demo every week, and finishes with production access, runbooks and a handover call. Our SaaS product engineering work is where that starts.