Concept for Lovable

What should an AI app builder do when it's stuck?

Role: Self-initiated concept
When: October 2026, one weekend
Platform: Web
Made with: Claude Code, prototyped in HTML and JavaScript

Starting point

I built a small notes wall in Lovable. The first page came together in minutes. Then I asked for one real feature, sign up and login, and it used up all my free credits. Public reviews tell the same story at scale: in a summary of 1,800+ reviews, about half of the pain points are about credits, often spent on fixes that create new problems.

Outcome

Three moments that change when the AI acts and when it asks: a plan before any fix, an honest stop after two failed fixes, and locks for the parts of your app that already work. A working prototype you can click through below.

Failing isn't the problem. Every AI gets things wrong. The problem is failing confidently, again and again, with someone's credits. When a fix costs money, the AI should earn the right to try it.

One rule behind all three moments

I used the same two questions I designed around on Proofroom: how sure is the AI, and what will acting cost you? Sure, cheap and easy to undo, it can act and show what it changed. Unsure, it says so before spending anything. Wrong twice, it stops guessing.

Try it: switch between the three moments at the top, and click the buttons inside the chat. Open the prototype full screen

Three moments

1. Before a fix

Today you press fix and find out afterwards what it touched, and whether it worked.

The AI shows what it thinks broke, how sure it is, which parts it will and won't touch, and what it costs. Then you choose: fix, ask why, or say "that's not it" for free.

2. After two failed fixes

A third guess usually costs another credit and makes things worse.

It stops and says so. It lists what it knows and what it doesn't, then offers a free way back to the last working version, a deeper look before changing anything, or a chance to explain what you expected.

3. Lock what works

Reviewers describe the AI overwriting parts that were fine.

Lock any part of the preview. Every plan lists what it won't touch, and to change a locked part, it asks you first.

What I'd test next

This hasn't been tested with users yet. To start, I'd measure three things: how many fix attempts it takes to solve an error, how often people go back to a working version instead of trying again, and whether people who see a plan first spend fewer credits per error. I'd also want to learn when the plan card helps, and when it just gets in the way of someone who's moving fast.