You change a button colour and the contact form stops working. Learn why fixes spread, how to log each break and what it takes to stop the loop for good.
ChatGPT
Claude
Google
GrokYou asked for the pricing table to be updated. It was. Now the menu doesn't open on phones. That gets fixed, and the contact form stops sending. Every small request turns into two new problems.
That loop can point to how the site is put together. A record of each break, plus a check after every change, helps distinguish an isolated repair from a structural problem.
Why does fixing one thing break another?
Most websites are built from shared parts. That's normally a good thing, until nobody knows what shares what.
Small changes keep breaking a website when its pages depend on shared styles, components or code that a change touches without anyone checking the rest, or when the same code was copied into several places so a fix only reaches one of them. The break isn't random: it follows those hidden connections.
Three patterns worth checking:
- Shared parts changed for one page. A button, card or heading style is used across the site. Someone adjusts it to fix the pricing page, and every other page using it changes too.
- Copies instead of shared parts. The same menu or form was pasted into several pages. A fix reaches one copy; the others keep the old bug, so it seems to "come back".
- Nobody rechecks the rest. The change is tested on the page it was meant for, then published. Nothing checks the contact form, the checkout or the phone menu.
A hypothetical example: the homepage "Book a call" style is also used on the form's Send button. Making the homepage button wider also hides the Send text on small screens. The homepage looks right; the form now has an empty button on phones.
Can you undo it while you investigate?
Yes, and it's usually the first thing to do. Go back to the last version that worked, then find the cause without customers waiting.
- Vercel: Instant Rollback puts a previous production version back live without rebuilding it. On the free Hobby plan, you can only go back to the previous deployment. Settings changed since then aren't rolled back with it. After a rollback, ask your developer to promote the corrected deployment so new pushes can go live automatically again.
- Lovable: every change is saved as a version. Open History, choose the version and click Revert to this version. That restores the code only, not the data in your database. Bookmark versions that work, so they're easy to find.
- Builders and other hosts: most keep a version or deploy history. Look for "History", "Versions" or "Deployments" in your dashboard.
Before reverting a site with accounts or orders, ask your developer to check that the older code still works with the current data. A code rollback does not undo database changes. Then request a smaller change, with the checks below.
How do you keep a breakage log?
A log turns "it keeps breaking" into useful evidence. Keep it for two weeks or five changes.
For each break, write down four things:
| Column | What to write | Example |
|---|---|---|
| What changed | The request, who made it and when | "Wider homepage button, 3 Oct, via the AI builder" |
| What broke | Page, device and browser | "Contact form Send button empty, iPhone, Safari" |
| How to repeat it | The steps to see it again | "Open /contact on a phone, scroll to the form" |
| What fixed it | The change, and whether it held | "Button style split in two, held after next update" |
Add a screenshot and any red error from the browser console. Lovable's debugging guide asks for the same things when reporting a bug: what's broken, where, what you expected and what happened instead.
What should you check after every change?
A short check of the paths that make you money helps catch breaks before customers do. Start with ten minutes; complex booking or checkout flows may need longer.
Run this list after each change, on your phone and a computer:
- The homepage loads, and the main menu opens and reaches every key page
- The main button on the homepage goes where it should
- A test enquiry from the contact form arrives in your inbox
- Booking, sign-up, login or checkout works from start to finish
- One page you didn't change still looks right
- The browser console shows no new red errors after a reload
Give the fourth item extra attention, because forms, logins and payments depend on several parts working together. If one fails, our guides to buttons that don't work and contact forms that don't send help you narrow it down.
Ask whoever makes changes to publish them to a preview address first, run the list there, then publish. A change that only breaks on the live address points to a different problem, covered in why a site works in preview but not live.
What does your log tell you?
After two weeks, read the log as a whole. The pattern tells you what to investigate first.
| What the log shows | Possible cause | What to ask for |
|---|---|---|
| Changes to one page break others | Shared styles or parts changed for a single page | Separate styles for the exception, or a change to the shared part on purpose |
| The same bug keeps coming back | Duplicated code or a later change overwriting the fix | Trace the returning bug and keep the fix in the shared source |
| Breaks follow AI builder requests | The tool may be editing more than the request needs | Smaller requests, one change at a time, a revert when it goes wrong |
| Breaks only appear after publishing | The live setup differs from preview | A check of the live settings and connections |
| Breaks follow updates to plugins or packages | Outside code changed underneath the site | A record of versions and a test before updating |
One row with a clear cause is often a single repair. Several rows at once suggest the structure itself needs a closer look.
Is it always a new break?
Not every "broken" report is a new problem. Rule these out before you log it.
- An old version in your browser. Open the page in a private window. If it looks right there, cached files, an extension or your signed-in session may explain the difference.
- A change that hasn't finished publishing. Check the deployment status in your host's dashboard. Wait until it finishes, then check again.
- Content, not code. A very long headline or a large image added in the editor can push a layout apart without any code changing.
If the problem persists, log it.
If every fix on your site creates a new break, we can find the shared cause and repair it properly. On a custom-coded site, we trace what each part depends on, fix the source rather than the symptom and quote once we know how deep it goes. An AI-built SaaS product or MVP that has to keep working gets cleaned up on its existing codebase; an AI-built marketing site is usually quicker and cleaner to rebuild. A Framer site we can repair in place, while recommending a move to custom code; for Webflow, we'd talk about a rebuild. Book a free intro call that doesn't commit you to anything, or reach us at hi@aruno.studio, on WhatsApp or Telegram at @mihaipostelnicu.
What does a lasting fix include?
The goal is a site where a small change stays small.
- Shared parts that are meant to be shared. One button style, one menu and one form, used everywhere and changed in one place, on purpose.
- Exceptions kept separate. A page that needs something different gets its own setting instead of altering the shared one.
- Automated checks on the main paths. A developer can write tests that open the site, send a test form and complete a sign-up after every change. They catch breaks before anything goes live.
- A record of changes. Every change in a code history such as GitHub, with a short note, so a bad one can be found and undone.
Ask for these in the quote.
Frequently asked questions
Should I rebuild my website if it keeps breaking? Not automatically. If your log points to one or two weak spots, a repair is usually enough. If almost every change breaks something different, or the site was built quickly with an AI tool as a marketing site, compare a rebuild quote with the cost of repairing it piece by piece.
Why does my AI builder keep bringing back bugs it already fixed? Usually because the same code exists in more than one place, or because a new request rewrites a part that held the earlier fix. Revert to the last working version, then ask for one small change at a time and run your ten-minute check after each.
Will automated tests stop my website breaking? They won't stop mistakes, but they catch many of them before customers do. Tests for the main paths, such as the contact form and checkout, are the most useful place to start.
Can I avoid breaks by not changing anything? For a while, but outside services, browsers and security updates keep changing around your site. Our guide to website maintenance costs covers what regular upkeep involves.
The next small change doesn't have to break anything. Start the log today, run the ten-minute check after the next update and let the pattern tell you what to fix.
Share this article:
