Lovable keeps breaking the same feature: how to stop it

Why Lovable keeps breaking the same feature

Lovable's Build mode edits your project directly, and its pricing is usage-based: Lovable's docs say cost depends on files modified, logic complexity, how much of the codebase it explored, and tools like browser checks. A fix is not a small, precise edit the way a developer would make one. It's a fresh generation that can touch files it didn't need to, which is how a dashboard fix reaches the login.

Three things make the loop tighten. First, every attempt costs credits whether it works or not. Second, each failed fix leaves code behind, so the next attempt is working on a messier app than the last. Lovable's debugging guide says exactly this: repeated blind fixes tend to pile up code that hides the real problem. Third, "still broken" gives the model nothing new, so it tries a variation of the same change. After three or four rounds, the original bug is buried under the fixes for it.

The way out is to stop feeding the loop, go back to a clean version, and give Lovable, or a person, the one thing it was missing: the actual error. If you want to know what fixing a Lovable app costs in general before reading on, the cost to fix a vibe-coded app covers every size of job.

Step 1: stop clicking fix and set a credit limit

The Try to fix button is the first thing to understand, because it changes what each click costs. Lovable's docs say your account includes 10 free fixes, shared between Try to fix and fixes from the Security view, and each one becomes available again 24 hours after you use it. After the 10 are gone, Try to fix still works, but it's treated as standard build usage and consumes credits. So the first couple of clicks on a new error are close to free. The tenth click of the day is not.

Lovable's own debugging guide says to use Try to fix once or twice, then describe the bug, then switch to Plan mode rather than retrying blind fixes. I'd go stricter:

• Two attempts per error. One Try to fix, one described fix. If the error is still there, the cause is not what Lovable thinks it is, and a third attempt is paying to find that out.
• Look at the cost before the next prompt.Under every reply, the More options menu shows a Credits used line. Lovable's docs say this is what it already charged, not an estimate. Three fixes that cost 1.2, 2.4, and 3.1 credits are getting more expensive because the app is getting messier.
• Stop the request if it starts touching other files. A stopped Build request is charged for work completed, but a request stopped before Lovable changes the project isn't charged at all.

For scale: the Pro plan starts at $25 a month for 100 credits, and Lovable's illustrative costs are 0.50 credits to make a button grey and 1.20 to add authentication. A fix loop that eats 30 credits on one bug has spent almost a third of the month's allowance on nothing you kept.

Step 2: revert to the version before the bug

Don't fix forward from a tangled version. Go back to the last one that worked. In Lovable, click the History toggle in the top bar, or open Project, then History, next to the chat input. The panel lists every version, and clicking one opens a read-only snapshot you can check before committing to it. Click Revert on the version you want, and confirm.

Pick the version from before the firstsymptom, not the one right before the latest crash. The versions in between are the failed fixes, and keeping any of them keeps the mess. If you're not sure which message caused it, View in chat on each version shows the matching message.

What a revert does and doesn't do

Lovable's docs say reverting restores the project's code only. Edge functions are redeployed to match, but data changes and migrations made after that version remain, and the later messages stay in the chat so you can reapply what you want. Revert is also all-or-nothing per version: to undo one change inside a version, you ask in chat instead. And reverting doesn't refund anything, since credits pay for work performed even if you later undo it.

Two habits save this step next time. Bookmark a version whenever something important works, with Bookmark in history on the activity card, so you're not scrolling through forty versions under pressure. And make one change per message, so the version right before a bug contains only working code.

Step 3: restate the bug with the exact error text

From the clean version, describe the bug once, properly. The difference between a fix that works and the loop is usually the information in the prompt. "Login still broken" makes Lovable guess. The exact error, where it appears, and what you expected lets it look in the right place.

Get the error text from the browser, not from memory. In Chrome, right-click the page, choose Inspect, then the Console tab, and copy the red lines. If the bug only happens on the published site, Lovable's docs say pasting the exact message from your browser's developer tools or your backend logs still helps, even though Lovable reads console logs in the preview on its own.

Then use Plan mode, not Build. Lovable's docs say Plan mode investigates and writes a plan without touching your code, for one credit a message plus any research it runs. Ask it to find the root cause and list which files it would change. If the plan touches files that have nothing to do with the bug, that's your warning before any code moves. Only approve a plan that changes one or two files you'd expect.

Investigate only. Do not change code yet.

What's broken: Login with email and password.
Where: /login on the published site, also in preview.
Since: the version from 3 Nov, 14:20, "add usage chart to dashboard".
What I expected: redirect to /dashboard after sign-in.
What happens: the button spins, then this error in the console:
  TypeError: Cannot read properties of undefined (reading 'session')
  at AuthProvider.tsx:41

Find the root cause. List the files you would change and why.
Do not touch the dashboard.

If this fixes it, you're done and the whole detour cost a few credits. If the same error comes back after a clean revert and a precise prompt, it's structural, and the next step is to take the fix out of Lovable.

Step 4: export to GitHub and fix the file by hand

A bug that survives a revert and a precise prompt is usually a five-line change a developer makes in one file: a missing null check, a hook used in the wrong place, an environment variable read on the wrong side. Lovable regenerating a whole component to make that change is where the collateral damage comes from. Making the change directly avoids it.

Lovable's GitHub sync is built for this. From Project settings, then Git, you connect GitHub and Lovable creates a private repository and starts two-way sync. Changes made in Lovable push to GitHub, and changes pushed to the active branch sync back into Lovable. So you, or the developer you hand this to, edits one file in a normal code editor, pushes, and the fix appears in Lovable without a prompt and without credits. You keep using Lovable for everything else afterwards.

Three sync rules that catch people out

• One branch syncs. Only the active branch, the default one unless you switch it. Pushes to other branches do nothing until merged into it.
• Don't edit in both places at once. If Lovable and GitHub have diverged, Lovable pushes its work to a lovable-syncbranch instead, and a later sync from GitHub can replace Lovable's version. Pause prompting while the hand fix is in progress.
• Sync always creates a new repository.You can't connect an existing one, and reconnecting after a disconnect makes another new repo.

Doing this yourself means reading the file and the error together, which is a developer's job. The guide to hiring someone to fix a Lovable app covers how to brief one and what access to give. For a single bug like this, the access is the GitHub repo and a read-only look at the Supabase project.

What a developer charges to break a Lovable fix loop

Compare the two bills before deciding. In credits, Lovable's top-ups cost $15 per 50 credits on Pro and $30 per 50 on Business, and the Pro tiers run from $25 for 100 credits a month to $2,250 for 10,000. A loop that burns 150 credits across a week is $45 of top-ups on Pro, plus the week. The bug is still there.

My prices are the last two rows. The Launch-Ready Review is the right size when the loop has hit more than one feature, because the same structural cause is usually behind all of them, and the review finds it once. The fee comes off the Production Sprint if you continue.

When the loop means the app has outgrown prompting

One loop on one feature is normal. A pattern of loops is a signal. These are the signs I look for when a founder sends me an app:

• The same kind of bug returns on different features: anything that touches login, or anything that reads the current user.
• A fix in one place reliably breaks another, which means the parts share code they shouldn't.
• The app has real users or payments, so each broken deploy now costs trust, not just credits.
• You've stopped adding features because every change is a risk.

None of these mean the app is wasted. The screens and flows Lovable built are usually fine. What's missing is the layer underneath: who can read which data, how sessions behave, where the keys live, what happens when a payment fails. That layer is what vibe-coded app rescueis, and whether you need it or just a hand fix is the first thing a review settles. If you'd rather check yourself first, the free vibe-coded app launch checklist runs through the same items in ten minutes.

An AI-generated demo that couldn't be prompted into a product

The Chat Companycame to me as a demo that the founder and another developer had generated with AI tools. It showed the idea, a chatbot trained on a business's own website, and it couldn't serve real businesses. More prompting wasn't going to get it there: the problems were in the layer underneath the screens, which is the fix loop at product scale.

I reviewed all of the code before changing anything. About 20% was general backend code that worked, so I kept it. The other 80% I rewrote, then built the rest of the product on that foundation: a website crawler, an answer engine on OpenAI, a one-script widget, conversation analytics, and a support desk. It took nine weeks and $20,000, and it now serves 30 or more businesses handling 100,000 messages a day.

The lesson for a smaller app is the same one as step 2: reading what exists before touching it, and keeping what works, is faster than regenerating. If the loop you're in is one feature, that reading takes an afternoon. If it's the whole app, that's what the fix or rebuild decision is about.

A stop rule and bug report template to keep

Pin this next to the editor. It's the whole method in a form you can follow at 11pm with a launch tomorrow.

And the bug report, in the order Lovable or a developer needs it: what's broken, where, since which version, what you expected, what happens, the exact error with the file and line, and what not to touch. The prompt in step 3 is this template filled in. Keep the empty version:

Investigate only. Do not change code yet.

What's broken:
Where (page or URL, preview or published):
Since (version or message that introduced it):
What I expected:
What happens, with the exact error text:

Find the root cause. List the files you would change and why.
Do not touch:

What to do next

If you're in the loop right now: stop, revert, send one precise prompt in Plan mode. That resolves most single-feature loops for a credit or two. If the error survives that, don't buy a top-up. Export to GitHub and get the file fixed by hand.

If this is the third feature to loop this month, or the app has users and payments, send me the app's link and the error text and get in touch. I'll tell you within a day whether it's a one-file fix or something the review should look at first. If you're weighing moving off Lovable entirely, the guide to moving a Lovable app to your own hosting is the honest version of what that involves.