---
title: "Lovable app stuck? Fix it, build on it, or start again"
description: "Lovable app broken or stalled? What you own, why it stuck, who pays for the failed attempts, and how we decide whether to fix, finish or rebuild it."
canonical: https://www.clientflow.ai/guides/stuck-with-a-lovable-build
category: Rescue
authors: ["Sohail Chowdhary"]
published: 2026-09-04
verified: 2026-09-04
language: en-GB
---

# Stuck with a Lovable build? Here is what to do

What you actually own, why projects stall, who has been paying for the failed attempts, and the three outcomes we choose between before quoting a fixed price.

By Sohail Chowdhary · Published 4 September 2026 · Verified 4 September 2026 · 15 min read

**Summary:** A stuck Lovable project ends one of three ways: fixed, built on, or started again, and which one fits is a question about the code and the database, not about what you have spent. The code is a standard React project you own; the database you may or may not own yet. Most projects stall in the same places: permissions, the data model and a fix loop that bills you per attempt whether or not the attempt worked. On a free twenty-minute call we say which outcome we think it is, then read the code and the database before we put a fixed price on it, and the AI bill for the work is ours, never yours.

## Contents

1. [The short answer](https://www.clientflow.ai/guides/stuck-with-a-lovable-build#the-short-answer)
2. [What you actually have](https://www.clientflow.ai/guides/stuck-with-a-lovable-build#what-you-actually-have)
3. [Why it got stuck](https://www.clientflow.ai/guides/stuck-with-a-lovable-build#why-it-got-stuck)
4. [Who pays for the attempts](https://www.clientflow.ai/guides/stuck-with-a-lovable-build#who-pays-for-the-attempts)
5. [The security check, before anything else](https://www.clientflow.ai/guides/stuck-with-a-lovable-build#the-security-check)
6. [Fix, build on, or start again](https://www.clientflow.ai/guides/stuck-with-a-lovable-build#fix-build-on-or-start-again)
7. [What a migration involves](https://www.clientflow.ai/guides/stuck-with-a-lovable-build#what-a-migration-involves)
8. [When to stay on Lovable](https://www.clientflow.ai/guides/stuck-with-a-lovable-build#when-to-stay-on-lovable)
9. [Questions people ask before a rescue](https://www.clientflow.ai/guides/stuck-with-a-lovable-build#questions)

## 1. The short answer

There are three ways a stuck Lovable project ends: it gets **fixed**, it gets **built on**, or it gets **started again** with what you learned. Which one fits is a question about the code and the database, not about how much you have spent, and we answer it before we quote.

The call is free and takes twenty minutes. Bring the Lovable link and, if you have one, the GitHub repository. If the answer is a few hours of fixes, we will say so and you will not need us. If it is a version one with a head start, we read the code and the schema, and the price we give you is fixed from that reading.

- **Apps with an open database**: 170 of 1,645 scanned (The March 2025 scan behind CVE-2025-48757, about one in ten[^10])
- **One Lovable credit on Pro**: $0.25 each ($25 a month for 100 monthly credits[^7])
- **Adding sign-up and login**: 1.2 credits (Lovable’s own worked example of what one instruction costs[^6])

## 2. What you actually have

The good news first. Lovable’s own documentation says you are never locked in, and that a Lovable application is a standard Vite and React project with no proprietary frameworks and no hidden dependencies[^1]. The code can be synced to a GitHub or GitLab repository at any time, cloned, edited outside Lovable and hosted anywhere[^2]. That is true, and it is why a rescue is possible at all.

The part people miss is that the code is only half of the app. The other half is the database, the user accounts and the server-side functions, and where those live depends on a choice made early, often without knowing it was a choice.

| Part | Where it lives | Can you take it? |
| --- | --- | --- |
| **The code** | A Vite and React project, synced to a repository you own if GitHub sync is on[^2] | Yes. Clone it and it runs anywhere[^1] |
| **Database on Lovable Cloud** | Lovable’s built-in backend, which runs on Supabase’s open-source foundation[^3] | Your data exports. The schema has to be rebuilt by hand in a Supabase project of your own[^3] |
| **Database on your own Supabase** | A Supabase project in your account, billed by Supabase[^4] | It is already yours. Disconnecting Lovable changes nothing in it[^4] |
| **Sign-in and users** | Wherever the database is | With your own Supabase, they come with the project. On Cloud, take the export before you remove anything: removing Cloud deletes it and cannot be undone[^3] |
| **Hosting and domain** | Lovable publishes the app and serves a connected domain | The published app stays live if you downgrade, but an app on Cloud or using AI features needs credits to keep serving requests[^5] |

Read from Lovable’s documentation on the date in the sources. The Cloud line is the one that decides how much of a migration there is.

So the first thing we ask is not “what does the app do” but “where is the database”. Your own Supabase project means the data, the users and the policies are already in your name and the move is a code move. Lovable Cloud means the data comes out as an export and the structure is rebuilt, which is real work and is priced as such.

## 3. Why it got stuck

Almost every stuck project we see stalled in the same places, and none of them are the easy parts. The landing page, the forms and the dashboard came fast. What stopped was the part where the software has to be right rather than plausible.

- **Permissions**: Who can see which rows. Lovable’s own guidance is that before going live every table needs Row Level Security policies restricting who can read and write each row, and that missing policies are the most common way app data gets exposed[^4]. It is also the thing a prompt is least likely to get right, because the app looks identical whether the policy exists or not.
- **The data model**: Tables that grew one prompt at a time. Customers with three different address fields, orders that do not know which price they were sold at, a status column that means four things. Every feature after this point is built on it, and every fix disturbs it.
- **Integrations**: The accounts package, the calendar, the payment provider. A generated integration works for the demo and fails on the case the demo did not include: a refund, a timezone, a customer with two accounts.
- **Branching logic**: Rules with exceptions. Approve unless the value is over the limit and the requester is not a director. The model can write the rule; what it cannot do is hold every other rule in its head while it does, so the fix for one breaks another.
- **Roles**: A customer view and a staff view are two products sharing a database. When they were added as a second prompt rather than designed as a second product, the seams show wherever the two meet.

Underneath all five is the loop. Each fix is a fresh request to a model that sees the code but not the intent, so it fixes what you pointed at and disturbs what you did not.

The standard advice for the loop is sound: revert to a version that worked, plan before you build, and make one small change at a time. The reason people still end up here is that by the fifth or sixth cycle nobody, including the model, holds a picture of the whole system. That picture is what a developer is for.

## 4. Who pays for the attempts

Lovable is priced in credits. On the Pro plan that is $25 a month for 100 monthly credits, with five more a day on top[^7], which makes a credit about 25 cents.

Lovable’s pricing page gives worked examples of what an instruction costs: making a button grey is 0.50 credits, removing a footer 0.90, adding authentication with sign-up and login 1.20, a landing page with generated images 1.70[^6]. Planning without building is a flat credit per message[^6].

Under the hood those credits buy calls to a model. Lovable runs an agent on Anthropic’s Claude models, with subagents for different parts of a task[^8], and Anthropic sells the same models directly at published prices, from $1 to $25 per million tokens depending on the model[^9]. What one credit buys in tokens is not published, so we will not put a multiple on it.

Two things are certain. The meter runs on every attempt, including the ones that broke something. And unused monthly credits expire two months after they are issued[^6], so a project that stalls for a quarter loses the credits it did not use as well as the ones it did.

> **You never front our AI bill**
>
> We use the same models to build. The cost of every attempt, including the ones we throw away, is inside the fixed price. You pay for working software, once, and a failed attempt costs you nothing. That is the whole difference between a tool that bills per message and a studio that quotes a number.

This is not an argument against Lovable’s price. At $25 a month it is fair value for a tool that gets a prototype in front of people in an afternoon. The wider case for owning software rather than renting it is in the [own-or-rent guide](https://www.clientflow.ai/guides/build-or-buy-software-uk).

It is an argument about where the risk sits once the prototype has to become a system. On a per-attempt meter the risk of not knowing how many attempts it will take is yours. On a fixed price it is ours, and we are the ones who can see the work.

## 5. The security check, before anything else

Whatever the outcome, this comes first, and it should come first for you today even if you never speak to us.

In March 2025 a researcher scanned 1,645 Lovable-built sites and found 303 endpoints across 170 of them, about one in ten, that could be read or written without logging in, exposing names, phone numbers, subscriptions, payment details and API keys[^10].

It was recorded as CVE-2025-48757 and scored 9.3, critical: an insufficient database Row Level Security policy in Lovable through 15 April 2025 allowed remote unauthenticated attackers to read or write arbitrary tables of generated sites[^11].

Lovable disputes the record on the grounds that customers are responsible for protecting their application data[^11], and in April 2025 it added a scan that runs before publishing, built on Supabase’s Security Advisor, to flag tables without policies[^12].

The policies are the customer’s responsibility, and a customer who has never heard of a policy cannot write one. A green tick from a scanner that checks whether a policy exists is not the same as a policy that restricts anything; a policy that allows everything passes the first test and fails the second. So we do not read the scanner, we read the policies.

**Do**

- Turn on Row Level Security on every table and write a policy that names who can read and who can write. Then test it as a logged-out user, not as yourself.
- Check every storage bucket is private unless it holds public assets, and that uploaded files are not listable.
- Rotate any key that has ever been pasted into a prompt or shipped in the front end. The public key that Supabase apps use in the browser is designed to be public; it only protects you if the policies behind it do.

**Don’t**

- Treat a passing scan as a passing system. It reports that a policy exists, not what it allows.
- Put a service-role key, a payment secret or a private API key anywhere the browser can see it.
- Wait until after launch. The data that leaks is the data you collected while you were waiting.

## 6. Fix, build on, or start again

We read the repository and the schema, run the app, and list what is real: which features work end to end, which work for the demo path only, and which are screens with nothing behind them. Then the decision is usually obvious, and it comes down to five signals.

| Signal | Fix | Build on | Start again |
| --- | --- | --- | --- |
| **The data model** | Sound. The tables mean what they say. | Mostly sound, a few tables to reshape and a migration to write. | The model itself is wrong: the same fact lives in three places, or the thing you sell is not a table. |
| **Permissions** | Policies exist and restrict; gaps are a day’s work. | Policies are missing on some tables; the fix is real but bounded. | Nothing restricts anything, and data has already been collected. |
| **What works** | Most of it, end to end. | The screens and flows are right; what is behind them is thin. | The demo path works and nothing else does. |
| **Integrations** | Connected and handling the edge cases. | Connected for the happy path; the failure cases are the work. | Faked, or built against the wrong system. |
| **What you need next** | The same product, working. | The same product plus the next workflow. | A different product from the one the prototype taught you to want. |

Two of five in the last column and the code is a prototype, not a foundation. That is not a failure: the prototype did its job, which was to tell you what to build.

A fix keeps the repository and the database and closes the list. A build-on keeps the front end and the parts of the schema that are right, moves the database into your own Supabase project if it is on Cloud, hardens the policies, adds tests around the flows that matter, and takes Lovable out of the loop so the app runs on hosting and a domain in your name.

A start-again keeps the learning and, usually, the design, and treats the rest as a spec. In every case the code is not the asset. The knowledge of what the business needs, which the prototype made concrete, is.

Each is priced from a blueprint, the written scope every build starts with, and the floor is the same £10,000, because a rescue worth doing is a version one with a head start.

The [cost guide](https://www.clientflow.ai/guides/bespoke-software-development-cost-uk) has the bands and the five things that move a build between them. If you want us to do the takeover, the [Lovable takeover page](https://www.clientflow.ai/lovable-agency) says what we read first, what it costs and what you own afterwards.

## 7. What a migration involves

A build-on is the outcome most stuck projects land on, so here is that path in full. A fix is the first three steps; a start-again is the delivery process in the cost guide, with a prototype to point at.

1. **Blueprint call** · Free · Day one

   Twenty minutes. Bring the Lovable link, the repository if there is one, and the list of what does not work. We tell you which of the three outcomes we think it is and why.

2. **Read** · Audit · Week 1

   We clone the repository, run it, read the schema and every policy, and write down what is real. If the database is on Lovable Cloud, we take the export now, before anything is changed.

3. **Blueprint** · Scoped · Weeks 1 to 2

   The outcome in writing, with what is kept, what is rebuilt, what is dropped, and one fixed price. This is where the reading becomes a number that does not move unless the scope does.

4. **Build on** · Built · Weeks 2 to 6

   The database moved into your own Supabase project, a policy on every table, tests around the flows that carry money or personal data, the integrations finished for their failure cases, and the app deployed on hosting in your name. Lovable comes out of the loop; the code does not notice.

5. **Launch and handover** · Owned · Handover

   Every account in your name, the repository yours, your team trained, and the same warranty as any build: anything that does not do what the blueprint says is ours to fix.


The published Lovable app can stay up while we work, because publishing is separate from the code, and it keeps serving after a downgrade as long as any Cloud or AI features have credits[^5].

And we ask you to stop prompting in Lovable once we have cloned the repository: the sync works on one branch at a time[^2], and two authors on one branch, one of them a model, is how the loop starts again.

## 8. When 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.

- **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. Keep it as that.
- **You are the only user.** An internal tool for one person carries no permissions problem, because there is nobody to keep out.
- **It holds no personal data.** A calculator, a configurator, a landing page. The security check above still applies to anything with a database, but the stakes are yours alone.
- **It works and you enjoy it.** Plenty of people are shipping real things this way and fixing them as they go. If the loop is not costing you sleep or customers, it is not a problem to be solved.

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. That is when the questions in this guide stop being hypothetical, and when a fixed price for a working system starts being the cheaper option.

**Bring the project as it is** Twenty minutes, no preparation and a straight answer about which of the three outcomes it is.

[Apply for a blueprint call](https://www.clientflow.ai/apply)

## 9. Questions people ask before a rescue

### My Lovable app is broken. Can you fix it, or finish it?

Usually one or the other, and the call tells you which. If the code and the data model are sound and the list is bugs and gaps, it is a fix. If the screens are right and what is behind them is thin, we finish it as a build-on. If the model itself is wrong, we say so and treat the prototype as the spec for a start-again. All three are priced from the blueprint after we have read the repository, not from the demo.

### Do I own the code Lovable wrote?

Yes. Lovable’s documentation says you own your code, that projects can be synced to GitHub or GitLab at any time, and that you can clone the repository, edit it outside Lovable and host it on your own infrastructure[^1]. If you have never turned on GitHub sync, do it before anything else; it is the copy that makes everything else possible.

### Will my app go offline if I stop paying Lovable?

Not on its own. Lovable says a published app stays live after a downgrade and connected domains keep serving it. The exception is an app that uses Lovable Cloud or AI features, which needs available credits to keep serving requests[^5]. That is the case a migration removes: once the app runs on your own hosting and your own database, there is nothing left to lapse.

### Can you work in my existing repository?

Yes, and we prefer it. The history is useful, and it is yours. We ask that nobody prompts in Lovable while we work, because the sync edits one branch at a time and two authors on it is how projects got stuck in the first place[^2]. When we are done, Lovable can stay connected or not; the app does not depend on it either way.

### My database is on Lovable Cloud. Is that a problem?

It is a piece of work, not a problem. Cloud runs on Supabase’s open-source foundation and your data exports, but Lovable says a move to your own Supabase project means rebuilding the schema by hand[^3]. We do that as part of a build-on, and we take the export before anything is changed, because removing Cloud deletes it and cannot be undone.

### How long does a rescue take, and what does it cost?

A fix or a build-on usually takes weeks rather than months: the read in week one, the blueprint by week two, the build-on in the four weeks after. The price is fixed from the blueprint like any build, with the same £10,000 floor. A start-again is a normal build, and the [cost guide](https://www.clientflow.ai/guides/bespoke-software-development-cost-uk) has the bands.

### Do you use AI to build as well?

Yes, the same models, with a senior engineer reading every change and tests around anything that carries money or personal data. The difference is not the tool; it is who carries the cost of the attempts that do not work, and ours are inside the fixed price.

### Is it safe to give you access to the project?

You add us to the repository and the Supabase project as collaborators, which you can revoke at any time, and a data processing agreement is part of every engagement, so any personal data in the database is handled in your name and under your instructions. Nothing is copied anywhere you have not agreed to.

## Sources

Every third-party figure above was read from the page cited, on the date shown. Vendors change prices without notice, so the date is part of the fact.

[^1]: [Lovable documentation, deployment, hosting and ownership options](https://docs.lovable.dev/tips-tricks/deployment-hosting-ownership). States that you are never locked in and that applications are standard Vite and React projects with no proprietary frameworks. Seen 4 September 2026.
[^2]: [Lovable documentation, GitHub integration](https://docs.lovable.dev/integrations/github). Two-way sync on one branch at a time; repositories private by default; clone locally and continue in your own editor. Seen 4 September 2026.
[^3]: [Lovable documentation, Lovable Cloud](https://docs.lovable.dev/features/cloud). Built on Supabase’s open-source foundation; data exports; moving to your own Supabase project means rebuilding the schema by hand; removing Cloud permanently deletes the instance. Seen 4 September 2026.
[^4]: [Lovable documentation, connect to Supabase](https://docs.lovable.dev/integrations/supabase). Your Supabase subscription is billed by Supabase; every table needs Row Level Security policies before going live; missing policies are the most common way app data gets exposed. Seen 4 September 2026.
[^5]: [Lovable documentation, publish your project](https://docs.lovable.dev/features/publish). A published app stays live after a downgrade; apps using Cloud or AI features need credits to keep serving requests. Seen 4 September 2026.
[^6]: [Lovable pricing page](https://lovable.dev/pricing). Worked examples of credits per instruction; Plan Mode at one credit a message; monthly credits expire two months after issuance. Seen 4 September 2026.
[^7]: [Superblocks, Lovable.dev pricing in 2026, 6 October 2025](https://www.superblocks.com/blog/lovable-dev-pricing). Pro $25 a month for 100 monthly credits plus five a day; Business $50 a month. Quoted from this review because Lovable’s pricing page does not publish its plan table as text. Seen 4 September 2026.
[^8]: [Anthropic, Lovable customer story](https://claude.com/customers/lovable). Lovable’s product runs a main agent with subagents on Claude models; 50 million projects built. Seen 4 September 2026.
[^9]: [Anthropic, Claude API pricing](https://claude.com/pricing). Haiku 4.5 $1 and $5, Sonnet 5 $2 and $10, Opus 5 $5 and $25 per million input and output tokens. Seen 4 September 2026.
[^10]: [Matt Palmer, statement on CVE-2025-48757, 29 May 2025](https://mattpalmer.io/posts/2025/05/statement-on-CVE-2025-48757/). 303 endpoints across 170 of 1,645 projects scanned on 21 March 2025; Lovable notified the same day. Seen 6 September 2026.
[^11]: [MITRE CVE record, CVE-2025-48757](https://www.cve.org/CVERecord?id=CVE-2025-48757). Published 30 May 2025; CVSS 9.3 critical; marked disputed, the supplier holding that customers are responsible for protecting their application data. Seen 4 September 2026.
[^12]: [Lovable, Secure vibe coding, 9 June 2025](https://lovable.dev/blog/secure-vibe-coding). Supabase’s Security Advisor integrated into Lovable; apps are scanned for security issues before publishing. Seen 4 September 2026.

## About the author

**Sohail Chowdhary**, Co-founder and technical lead. Sohail designs the architecture, builds the backend and reads every change before it ships. [LinkedIn](https://www.linkedin.com/in/sohail-chowdhary-23084289/)

## More guides

- [Build or buy? What the software you already pay for really costs](https://www.clientflow.ai/guides/build-or-buy-software-uk): £73,800 rented against about £20,400 owned, for a team of twenty over three years.
- [What bespoke software actually costs in the UK](https://www.clientflow.ai/guides/bespoke-software-development-cost-uk): The bands, the five things that move the price, and when not to build.

All guides: https://www.clientflow.ai/guides. Every guide is also served as Markdown at its URL with .md appended.