How do I undo a bad Lovable change?

Use Version history, not manual fixes

Lovable auto-saves a new version on every change it makes — there's no manual save step, and none is needed. To undo a bad change:

1. Open Version history.
2. Find the version from just before the problem was introduced (versions are timestamped, and you can preview each one before committing to it).
3. Revert to that version.

This restores the whole project to that exact state — code, structure, everything — rather than trying to describe the fix in a new prompt and hoping Lovable reconstructs the old behaviour correctly.

Bookmark known-good versions as you go

If you reach a stable point you're happy with (a working checkout flow, a finished design pass), bookmark that version. It makes it much faster to identify a safe fallback point later, rather than scrolling through a long, unlabelled history.

When reverting isn't quite right

If only part of the change was bad — say a new feature works but broke an unrelated page — reverting the whole project loses the good part too. In that case, it's often better to:

• Revert to before the bad change, then re-apply the good part with a narrower prompt, or
• Ask Lovable directly to undo the specific side effect: "the new checkout page broke the homepage header — fix the header without changing the checkout page."

What usually goes wrong

• Waiting too long to notice. The longer a bad change sits, the more later work is entangled with it, making reverting costlier. Check Preview after every meaningful prompt (see /questions/how-do-i-stop-lovable-changing-things-i-didn-t-ask-it-to-change).
• Trying to talk your way back to the old state with a new prompt instead of reverting — this is slower and less reliable than restoring the actual saved version.
• Forgetting Version history exists and manually re-building lost work from memory.

For genuinely large or risky changes, plan the revert point in advance — see /questions/how-do-i-safely-make-large-changes-to-a-lovable-project.