My Lovable app keeps breaking
A Lovable app keeps breaking because each prompt changes more of the app than you asked for, and nothing checks the parts you did not mention. Lovable sends your project and your request to a model, and the model edits files. A request to change the checkout button can touch the file that also works out the order total. Nothing in that loop clicks through the old flows again, so a break in one of them shows up when you or a customer finds it.
The fix is not a better prompt. It is a setup where every change is small, gets saved, and is checked against the flows that matter before it goes live. Part of that you can do inside Lovable today. The rest needs the code in a GitHub repository you own, with tests that run on every change.
If your app has no customers yet and breaks once a week, the steps below are probably enough. If people pay for it, read the last section too.
In founders’ words
“Multiple times, I've told it to do something and I've had to tell it two or three times to actually make the change or continue working on something.”
“My colleague now understands why unit tests, after watching subsequent development regularly break previous work.”
Why a change in one place breaks another
Lovable builds React apps, and in a React app one file often holds several jobs: a screen, the rules for what it shows, and the calls to the database. When you ask for a small change, the model rewrites the part of the file it thinks is relevant. It can be generous about what counts as relevant. A tidy-up it was not asked for, a renamed field, a helper function replaced by a new one: all of these look fine in the preview you are watching and break a screen you are not.
The database makes it worse. Lovable projects store data in Supabase, and a prompt that adds a column or a row-level security policy changes what every screen can read. The preview you test is also not the app customers use. Lovable publishes a snapshot, so what is live can be several edits behind or ahead of what you last looked at.
What to do inside Lovable today
- Connect GitHub first, in project settings. Lovable syncs the code both ways with a repository you own, so you have a copy outside Lovable and a record of every change.
- Use version history as a search tool, not only an undo. Find the last version where the broken thing worked and read what changed since. That is usually one or two prompts, and it tells you which file to point the model at.
- Ask before you build. In Chat mode, ask which files a change would touch and what else uses them. In Plan mode, read the plan before any code moves.
- One change per prompt, naming what must stay the same: "Change the button label only. Do not touch checkout or the orders table."
- Put standing rules in a Knowledge file: the payment flow, the tables, the screens that must not change unasked.
- List the flows that make you money. Click through them in a private window after every publish, as a new user.
- Try to fix is for build errors, not logic bugs. If it fails once, revert.
What Lovable's own tools cover, and what they do not
Lovable gives you version history, one-click undo, Try to fix for build errors, and a security scan that runs before publishing. The scan checks row-level security on your Supabase tables, known holes in the packages your app depends on, and keys left in the code. Lovable's own docs say these tools "cannot guarantee complete security", which is fair.
What Lovable does not give you: tests that run your flows after each edit, a staging copy with its own database, or any check on the published snapshot after it goes live. Git sync also stops at the code. Database changes sit in migration files in the repository, and Lovable does not run a new migration when a commit syncs. So the code and the database can disagree, and the app will tell you by breaking.
The setup that makes a fix stay fixed
What the app needs once it matters. None of it requires you to write code; a coding agent builds each piece if you ask for it by name.
- The GitHub repository is the source of truth. Lovable edits it, and so can Claude Code or Cursor, one tool at a time.
- End-to-end tests for the money flows: a script that signs up, logs in, pays and then does the one thing your product is for, the way a user would. They run on every commit in GitHub Actions and fail before a broken change ships.
- A staging copy with its own Supabase project. Changes go there first. The live app only changes when staging works.
- A rules file the agent reads every session: the stack, how to run the tests, what not to touch.
- Error alerts from the live app to your email or phone, so you hear about a break before a customer does.
This does not make bugs impossible. It makes each one show up once, in a test, instead of in front of a customer.
When you may not need help, and when you do
If nobody pays for the app yet, the steps above are enough, and a weekend of connecting GitHub and writing down your flows will cut most of the breakage. You do not need to hire anyone for that.
Bring in someone who has run software when customers pay, the same bug has come back three times, or you have stopped asking for features because you are afraid of what the next one will break. At that point the problem is in the structure, and a read of the whole codebase is the first step. We do that read, and we start with a free call, where we will tell you if you do not need it.
| What you see | Usual cause | First check |
|---|---|---|
| A page that worked last week is blank or errors | A later edit changed a shared component or a database column | Version history: find the last working version and read what changed since |
| Users can log in but see no data | A row-level security policy was added or changed without a matching rule | Supabase dashboard: the table's policies, then test with a second account |
| Works for you, not for a new user | Your account has data or a role a fresh account does not | Sign up as a new user in a private window and repeat the flow |
| Build error after a prompt | An edit left a file half-changed | Try to fix once; if it fails, revert to the previous version |
| Works in preview, broken after publish | The published snapshot is older than the preview, or a secret exists in one place only | Compare the published version with the preview, check Secrets, republish |
Questions
Does Lovable keep my code if I leave?
Your code stays in the GitHub repository once sync is on, and paid plans can download it directly. The database is a separate Supabase account you own. Lovable's own version history and chat stay in Lovable, so keep notes about decisions somewhere you control.
Should I move from Lovable to Claude Code or Cursor?
Moving tools does not fix the structure of the app; the same kind of model writes the code either way. Move when you need tests, a staging copy, and control over each change, and keep GitHub as the source of truth so one tool edits at a time. Many founders keep Lovable for screens and use a coding agent for the rest.
Can Lovable write tests for my app?
It can write test files when asked, but it does not run them for you after each edit. Tests only earn their keep when they run on every commit, which means GitHub Actions or a similar service outside Lovable.
Is the breakage because of the model Lovable uses?
A model change alters how the app is written, and people notice when quality drops. It does not change the underlying cause: edits with no checks on the parts not mentioned. A better model breaks things less often; it still breaks them.
How do I stop burning credits on fixes?
Revert after two failed attempts instead of asking a third time. Ask in Chat mode before building. Keep prompts to one change, and say what must not move. Each of those cuts the number of rounds, and the rounds are what cost credits.
First look, $750. After a free call, we read your whole product and tell you what is finished, what is not, and what to do first.
Setup, $3,000 fixed. We make it ready for real customers, in accounts you own.
Partner, $2,500 a month. We review what your coding agent writes and keep the checks and tests current. Month to month.