A client comes to us with a broken checkout button. The honest fix takes two hours: find the JavaScript error, patch it, ship it. But almost every time, that two-hour fix sits on top of a site that hasn't been meaningfully touched in three years — and the button was never really the problem, just the symptom that finally got noticed.
We patch it anyway, because a broken checkout button loses money today and a redesign conversation can wait until tomorrow. But we've learned to say, clearly, in writing: this is a patch, not a fix, and here's what it's not solving.
What a patch doesn't buy you
A quick fix solves the specific symptom someone noticed. It does nothing for the symptoms nobody's noticed yet — the slow product pages nobody's measuring, the mobile layout that breaks on one specific Android screen size, the form validation that silently fails for anyone using a non-Latin keyboard. Patches are, by definition, narrow.
The real cost shows up six months later, when three or four "quick fixes" have accumulated on the same aging codebase, each one a small workaround rather than a real solution, and now nobody on the team fully understands why the site behaves the way it does. At that point, even a simple future change becomes expensive, because every change has to be checked against a growing pile of undocumented patches.
When a quick fix is genuinely the right call
None of this means patches are always wrong. If a site is scheduled for a full rebuild in the next quarter, patching the checkout bug now and rebuilding properly later is the obviously correct sequence — rebuilding first would waste the redesign budget on code you're about to throw away.
The distinction we look for is whether the patch is a deliberate, time-boxed decision, or a default that quietly becomes permanent because nobody revisits it. The first is good triage. The second is how technical debt actually accumulates — not through one bad decision, but through many reasonable ones that never get revisited.
KEY TAKEAWAYS
- A quick fix solves the symptom someone noticed, not the ones nobody has measured yet.
- The real cost of patch-on-patch work shows up as slower, riskier changes later — not immediately.
- Patches are the right call when they're a deliberate, time-boxed decision — not a default nobody revisits.
This space is available for a relevant sponsor or partner. Get in touch to enquire about placement.
Not sure if you need a patch or a rebuild?
Send us the site and the specific problem — we'll give you a straight answer on which one actually makes sense.
Start the conversation →