A broken product does not get cheaper to fix one bug at a time. Each patch makes the next one more expensive, so the real decision is when to stop patching and what to rebuild first.
The position
Patching looks like the cheap option. Each bug has a ticket and a visible fix, while a rebuild looks like a large bet. That comparison leaves out the cost of the patches themselves. Every fix touches code that other parts depend on, so the cost of the next fix rises with the number of fixes already made. A rebuild is expensive, but it is one decision with an end date. Patching is a series of small decisions that never add up to one. Stop patching when a fix costs more than the part it repairs, and rebuild the shared decisions before anything else.
What's actually happening
The pattern is familiar to anyone who has taken over a product that works most days. The demo went well and the first customers signed up. Then the bugs start arriving in clusters. A change to the billing screen breaks the export. A fix to login logs people out of the mobile app. The team fixes whatever the support queue shows, and the list does not get shorter.
Estimates slip for the same reason. A ticket that looks like half a day takes a week, because nobody fully knows which other screens read the same data. The people who wrote the original code have moved on, or they are the only ones who understand it and they are busy with the next release. Every change needs someone who holds the whole system in their head, and there is usually only one such person.
The roadmap quietly turns into the bug list. New features wait, and the people who could build them spend their week in the same few areas that keep breaking. From the outside it looks like the team is working hard. From the inside, most of the effort goes into keeping yesterday's decisions alive.
We have been brought into projects in exactly this position. Earlier agencies had stalled them before we arrived, and the first question was never what to build next. It was which parts of the product were safe to change.
Why the obvious answer doesn't work
The obvious answer is to keep patching and reserve a rebuild for the case where the product is beyond saving. The trade-off most people miss is that the point where a rebuild becomes cheaper arrives earlier than the founder expects, and it is invisible in the ticket queue. Every patch looks like progress, so no single week looks like the week to stop.
Think of each workaround as a new dependency. A fix in one place relies on a quirk elsewhere, and the quirk becomes the next thing that breaks. After enough workarounds, the codebase reads like a list of exceptions, and nobody can say which exception is still needed. Removing one then means checking everything, which is why small changes start taking large amounts of time.
The opposite instinct fails too. "Start again" sounds clean, but a rewrite carries its own risk. The old product still has users, data and rules nobody wrote down. A full rebuild that runs in parallel for a year can cost more than the patches it was meant to replace, and it fails the same way the original did if nobody decides what the new one must do.
The real question is narrower. Which decisions does everything else depend on, and which parts are local? Data model, authentication, integrations and deployment are shared. A bug in a report page is local, and fixing it is cheap. A change to a shared decision is expensive every time, because it reaches every feature that reads it. Most of the money in a failed build goes to shared decisions that were never made explicitly.
What we do instead
- Stop feature work for a fixed period and map the failures. Group open bugs by the part of the system they touch, not by screen. Three bugs in one shared module tell you more than thirty bugs spread across separate screens.
- Fix the shared decisions first. Look at the data model, authentication, integrations and deployment. Make each decision explicit, write it down and change it once. A fix to a shared decision removes a whole category of future bugs.
- Test what users rely on before you touch it. Cover sign-up, payment and the main workflow with automated tests. A fix that breaks a tested flow shows up in the build, not in a customer's support ticket.
- Rebuild slices, not the whole product. Pick the area where a fix would cost more than a rewrite, rebuild it behind the same interface and run old and new side by side until the new one holds. The old system keeps serving users while the new one proves itself.
- Set a stop rule before you start. If a fix needs changes in three unrelated areas, it goes on the rebuild list. Agree the rule with the people who pay for the work, so the call is not made in the middle of an argument about a single bug.
If you run a product that works most days and breaks in new places each week, try this check. Find the fix from last month that touched the most unrelated screens and count them. That number tells you more than the size of the bug list.
When this doesn't apply
If the architecture is sound and the bugs are local, patch. A clean structure with a few faulty screens is a maintenance problem, not a rebuild, and a rebuild would waste money. Our software maintenance work is built for that situation.
If the product has little or no use yet, rebuilding is often cheaper than auditing. Nobody depends on the old decisions, so the cost of starting again is the cost of building it properly once.
Where to go next
- Related service: Product Engineering & Development
- A product we rebuilt after earlier attempts stalled: Sled Studio
- For products already in use: Software Maintenance
- How we work from scoping to release: our delivery approach
- Or talk to us: tell us about your project
Was this useful?
