Stuck with a Lovable build? Here is what to do

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.

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 dependencies1. The code can be synced to a GitHub or GitLab repository at any time, cloned, edited outside Lovable and hosted anywhere2. 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.

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.

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.

• PermissionsWho 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 exposed4. 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 modelTables 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.
• IntegrationsThe 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 logicRules 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.
• RolesA 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.

Lovable’s own 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.

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 top7, 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.706. Planning without building is a flat credit per message6.

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 task8, and Anthropic sells the same models directly at published prices, from $1 to $25 per million tokens depending on the model9. 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 issued6, so a project that stalls for a quarter loses the credits it did not use as well as the ones it did.

This is not an argument against Lovable’s price. Twenty-five dollars a month is a fair price 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.

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.

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 keys10.

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 sites11.

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

Both sides of that are true at once. The policies are the customer’s responsibility, and the customer was rarely told. 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.

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.

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 never the asset. The knowledge of what the business needs, which the prototype made concrete, is.

Each is priced from the blueprint, the way any build is, and the floor is the same £10,000 as any build, because a rescue worth doing is a version one with a head start.

The cost guide has the bands and what moves a build between them, and the five signals above are the same five things. If what you need is an afternoon of fixes, we will tell you on the call, and a good freelancer will do it for less than our floor.

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.

Two things about the move itself. 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 credits5.

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

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.

Questions people ask before a rescue