Home / Guides / Why updates break things
The usual cause is not careless developers. It is how the app is put together. Five causes in plain words, how to tell, and what fixes it without a rewrite.
Rajesh Ayyavu, TenlyrUpdated 2026-11-03Press the button to see what a single change can reach.
The short answer
The cause is usually how the parts are connected.
A change in one place quietly reaches others.
Map, add checks, keep each rule in one place. No rewrite.
Each card shows the pattern, what you notice, and what stops it.
In the early days it was faster to let every part of the app reach into every other part. Now one change ripples through many others, and the connections are not written down anywhere, so no one can predict what will break.
Without automated tests, the only way to know something broke is for a person to click through the app or for a customer to complain. As the app grows, nobody has time to check everything by hand.
The discount rule, the permission check and the tax calculation get copied into several screens. Someone updates four copies and forgets the fifth.
When two weeks of changes go out together, it is hard to tell which one caused the problem, and hard to undo only that one.
If one developer holds the whole picture in their head, every change depends on them remembering everything. When they are busy or leave, bugs multiply.
The honest answer is usually the system. The pattern tells you which.
A design problem needs a design fix. A process problem is cheaper to fix, and worth fixing first.
Almost never as a first step. It takes months, freezes new features and recreates the tangle if the causes are not fixed.
Even when a rewrite is justified, replacing one part at a time while the product keeps running is usually safer than switching everything at once.
Do not over-engineer. Add automatic checks to sign-up, payment and your core action now, and keep each business rule in one place. Cheap today, expensive to retrofit later.
Releases slow down as customers ask for more. Start with checks around billing and permissions, then split large releases into smaller ones you can undo.
Get the basics written down before anyone changes anything: how to run the app, how it is deployed, where passwords and keys live, and which outside services it uses.
AI tools write code fast but rarely add tests or clear boundaries. Add checks on your key flows and have someone review data access and security before adding features.
You do not need all five at once. Start where bugs hurt customers most. Ask your team this week for: a diagram of the main parts, a list of what the automatic checks cover, how a release goes out and how to undo it, and where pricing and permission rules live.
Four honest questions. Nothing is stored.
Can you release on a Friday without worrying?
Would you know within an hour if checkout broke?
Could a new developer safely change the billing code in their first month?
Do the same bugs keep coming back?
Written by Rajesh Ayyavu, founder and software architect at Tenlyr. He reviews SaaS products and fixes backend, database and AI problems. Last updated 2026-11-03. LinkedIn
Usually not. Repeated breakage is normally a sign of how the system is organised, such as tangled parts, no automatic checks and rules copied into many places. It is rarely about effort or skill. The exception is when one person's changes cause most of the problems, which points to missing review and process rather than the code.
Rarely. Most apps can be untangled step by step while they keep running. A rewrite is worth considering only when the technology is no longer supported, the core data design is wrong for your business, or security problems are built into the foundation. Even then, replacing one part at a time is usually safer than starting again.
It depends on the size of the app and how tangled it is. Often the first improvements, such as automatic checks on sign-up, payment and your main customer action, can be in place within a few weeks. Untangling the whole app is gradual and happens alongside normal work.
It depends on the app, so we agree a written scope first. The cheapest first step is an independent review that finds the few areas causing most of the breakage. You then spend on those areas instead of on everything, and you can show the report to any developer you choose.
With a small app, one person could keep everything in their head and a quick click-through caught most mistakes. As the app and the team grew, that stopped being possible, but the habits stayed.
They are the biggest single help, but only if they cover the flows that matter and run before every release. Tests added everywhere without a plan are slow to write and easy to ignore. Start with the five to ten flows your customers cannot live without.
These tools produce working code quickly, but they rarely add automatic checks, clear boundaries or security reviews. That is fine for a first version. Once real customers rely on it, add checks around sign-up, payment and data access before adding more features.
Take the free 30-question SaaS health checklist to see where the risk is, or request an Architecture Review. Rajesh replies personally within 2 business days.
Rajesh will review what you're building and reply personally within 2 business days.
