Skip to content

Lovable takeover

Lovable agency. Take over, migrate or rebuild.

A Lovable agency takes a build that started in Lovable and makes it a product you own. For teams whose build has stalled, or works and now has to hold other people’s data and money: we read the code and the database before we quote, fix what can be fixed, move the rest onto a stack in your name, and take Lovable out of the loop. One fixed price, set from a blueprint. Not a Lovable partner.

Bring the project as it isSee what we read first
A pixel-art heart with a sticking plaster across it, resting on a workbench with a spanner beside it.

What a Lovable agency does

Clientflow’s takeover reads the code and the database, fixes what can be fixed, moves the data into a Supabase project in your name, locks down the permissions, and takes Lovable out of the loop, so the app runs on hosting and a domain of yours. The price is fixed from a blueprint.

AspectIsIs not
ShapeA senior team reading the code and the schema before quotingAnother prompt, billed per attempt
Where it ends upYour repository, your Supabase project, your hostingA build that only runs while the credits last
The decisionFix, build on, or start again, decided from the readingA rebuild sold before anyone has looked
ControlThe code was always yours; the rest becomes yoursOne dependency swapped for another

The good news comes from Lovable itself: you are never locked in, and a Lovable application is a standard Vite and React project with no proprietary frameworks1, synced to a repository you own2. The half people miss is the database, the users and the server-side functions, which live wherever an early choice put them. That is the first thing we read.

The first week

Before a price, a reading: the code, the schema, every policy. This is what it looks like, and what it finds.

The policies, before anything else

Lovable’s own guidance is that before going live every table needs Row Level Security policies, the rules that say who can read which rows, and that missing policies are the most common way app data gets exposed4. In March 2025 a scan of 1,645 Lovable-built sites found endpoints on about one in ten that could be read or written without logging in7, recorded as CVE-2025-487578. So we do not run a scanner and call it done. We read the policies, and we test them as a logged-out user.

Fix it, build on it, or start again

We clone the repository, run it, read the schema and every policy, and list what is real: which features work end to end, which work only for the demo, and which are screens with nothing behind them. Then the decision is usually obvious. Each outcome is priced from that reading, and if what you need is an afternoon of fixes, we say so on the call and a good freelancer will do it for less than our floor.

  • Fix itHours to days
    Kept

    Everything. The app stays on Lovable.

    A specific breakage with a specific cause: a policy, a query, an integration that never handled its failure case. We fix it and you carry on, and you may not need us again.

  • Build on itWeeks 2 to 6
    Kept

    The code, the schema and what works.

    The head start is real. The database moves into your own Supabase project, policies restrict, the flows that carry money or personal data get tests, and the app deploys on hosting in your name.

  • Start again3 to 8 weeks of build
    Kept

    The data, and what you learned.

    When the data model is wrong at the root, building on it costs more than a version one. The export comes across; the app is rebuilt on the same standard stack, with a fixed price from the reading.

Moving off Lovable Cloud without losing the data

  1. ExtractionThe export from Lovable Cloud on day one, before anything is changed, because removing Cloud deletes the instance and cannot be undone.
  2. 2The schema, rebuiltCloud’s data can be exported, but the structure is rebuilt by hand in your project.
  3. 3Parallel runningThe published Lovable app stays live while we work, because publishing is separate from the code.
  4. 4CutoverHosting and the domain move to your name and Lovable comes out of the loop; the code does not notice.

Where the database lives decides how much of a migration there is. A Supabase project in your own account is already yours, and disconnecting Lovable changes nothing in it4. Lovable Cloud runs on Supabase’s open-source foundation and your data can be exported, but the schema has to be rebuilt by hand in a project of your own3, and that is real work, priced as such.

What you own on Lovable, and what you own after

The code was always yours: Lovable says so, and the repository proves it1. What a takeover adds is the rest: the database in a Supabase project in your name, hosting and the domain in yours too, the policies written and tested, and the intellectual property in everything we make for you assigned under the agreement. At handover you hold every account outright, including the ability to remove us.

Yours after the handover

The code was always yours. The rest is arranged before the build starts.

  • The codeA repository in your name, synced from Lovable or cloned from it.Yours
  • The databaseA Supabase project in your own account, not Lovable Cloud.Yours
  • The policiesWritten for every table and tested as a logged-out user.Tested
  • Hosting and the domainIn your name, with Lovable out of the loop.Yours
  • The intellectual propertyAssigned to you under the agreement.Assigned
  • LovableKeep the subscription or cancel it; the app no longer depends on it.Optional

That last part is worth checking with every supplier you speak to, because UK copyright law does not hand it over by default. The author of a work is its first owner9, the rule that gives an employer its staff’s work does not cover a contractor, and an assignment is only effective in writing, signed by the assignor10. Paying the invoice is not what transfers the copyright.

How much does it cost to take over a Lovable build?

A rescue worth doing is a version one with a head start, so the floor is the same £10,000 as any build, and the price is fixed from the reading rather than from the demo. A fix keeps the repository and the database and works through the list of what is broken. A build-on keeps the front end and the parts of the schema that are right. A start-again is a normal build: the bands are on the pricing page and what moves them is in the cost guide.

Builds from
£10,000
The reading
Week 1
To run, about
£800a year
The AI bill
Ours

The reading looks at five things: the data model, the permissions, what works, the integrations and what you need next. They decide the band, the way the five factors in the cost guide do for any build. Once it is live, a version one costs about £800 a year to run in your own accounts, itemised in the running-costs guide, with nothing per seat and no credits.

Who pays for the attempts

Lovable bills per attempt, including the ones that broke something, and unused monthly credits expire two months after they are issued6. The credit arithmetic is in the guide.

QuestionThe meterThe fixed price
A failed attempt costsYou, per instructionUs. It is inside the price
What you pay forEach attemptWorking software, once
Who holds the whole pictureNobody, a few prompts inThe engineer reading every change
Unused moneyCredits expire two months after issueThere is none to expire

We use the same models to build, with a senior engineer reading every change. The cost of every attempt we throw away is inside the fixed price, so you never see an AI bill from us.

How long does a takeover take?

A fix or a build-on usually takes weeks rather than months. The reading takes the first week, the blueprint turns it into one written price by the second, and a build-on runs from the second week to about the sixth. A start-again is a normal build: three to eight weeks after the blueprint. The published Lovable app stays up while we work5.

  1. 1Free
    Blueprint callDay one

    Bring the Lovable link, the repository and the honest list of what does not work.

  2. 2Audit
    ReadWeek 1

    The repository cloned and run, the schema and every policy read, the Cloud export taken.

  3. 3Scoped
    BlueprintWeeks 1 to 2

    The outcome, what is kept, what is rebuilt, and one fixed price.

  4. 4Built
    Build onWeeks 2 to 6

    The database into your own Supabase project, a policy on every table, tests around money and personal data, hosting in your name.

  5. 5Owned
    Launch and handoverHandover

    Every account in your name, your team trained, the same warranty as any build.

When we will tell you to stay on Lovable

Some calls end with us telling you to keep going, and we would rather that than take a project that does not need us. The moment to talk to someone is the moment the app starts holding other people’s data, taking their money, or standing between your team and their work. The cases in full are in the guide.

  1. It is a prototype and it is doing its job. If the point is to show an idea to customers, investors or your own team, a Lovable build is the fastest way to a thing people can click.
  2. You are the only user, or it holds no personal data, so there is nobody to keep out.
  3. It works and you enjoy it, and the prompting is not costing you sleep or customers.
  4. The fix is an afternoon, or the budget is under £10,000. We will say so on the call, and a good freelancer will do it for less.

Questions people ask before handing over a Lovable build

Sources

Every claim about Lovable above was read from the page cited, on the date shown; they are the same sources the guide uses.

  1. 1Lovable documentation, deployment, hosting and ownership options. Seen 4 September 2026.
  2. 2Lovable documentation, GitHub integration. Seen 4 September 2026.
  3. 3Lovable documentation, Lovable Cloud. Seen 4 September 2026.
  4. 4Lovable documentation, connect to Supabase. Seen 4 September 2026.
  5. 5Lovable documentation, publish your project. Seen 4 September 2026.
  6. 6Lovable pricing page. Seen 4 September 2026.
  7. 7Matt Palmer, statement on CVE-2025-48757, 29 May 2025. Seen 4 September 2026.
  8. 8MITRE CVE record, CVE-2025-48757. Seen 4 September 2026.
  9. 9Copyright, Designs and Patents Act 1988, section 11, legislation.gov.uk. Seen 5 September 2026.
  10. 10Copyright, Designs and Patents Act 1988, section 90, legislation.gov.uk. Seen 5 September 2026.

Go deeper

The guides behind the numbers on this page, each with its sources and the date they were read.