Evolution, not panic
"We will rewrite everything" sounds clean. Sometimes it is the most expensive way to throw away what works.
I heard a founder say: "The code is messy, we will toss it and build right." I asked how much revenue the system drives per month and how long a rewrite would pause the business.
The numbers did not line up. In 2026 you still see the same mistake: confusing shame about old code with a disciplined business decision.
I'm Naor. I join existing projects, patch, upgrade, and sometimes recommend partial or full rewrites. This article frames three paths without trashing legacy systems just because they are old.
Path A: Targeted Patches
Fits a focused bug, a small compliance tweak, or a security hole that must close fast. Risk: if every change is a band-aid without tests and dependency mapping, debt piles up and navigation gets harder.
Rule of thumb: if the fix takes days not months, and you know exactly what breaks if it fails, you are probably on the right track.
Path B: Incremental Upgrade (Strangler / Modules)
Fits when the system still serves customers, but one area eats time (reports, admin, a slow integration). You build a new module beside the old one, shift traffic gradually, and retire the old piece when nothing depends on it. This is often safest for a business that runs on today's software.
Path C: Full Rewrite
Fits when the stack is unsupported, security risk is unacceptable to patch, or small changes cost more than a clean build. A rewrite needs a fresh product spec: not "same thing but pretty", but flows, cadence, data, and integrations. Without that you rewrite in fog.
A point that saves money:
Before a rewrite, build a must-have capability list against the current system. Skip that step and you can spend a year missing a feature that was "obvious" in the old app.
Quick Decision Table (Minimal Philosophy)
- Risk of business stoppage: high if you touch the core? Prefer modules before a full cutover.
- Rate of requirement change: high? A long rewrite may be outdated before launch.
- Internal staff: nobody to maintain after? Plan maintenance as part of the project, not an appendix.
- Data and portability: no export and docs? Do not start a rewrite until that is sorted.
Summary
Legacy is not a tumor. It is often the asset that funds the next upgrade, if you treat it with a frame instead of tech shame.
Stuck on legacy and unsure what to do next?
Describe what the system does today and what hurts. We can map whether it is patch, module, or rewrite, without buzzwords.
Need help with your project?
Whether it's a website, bot, automation or something else - I'm here to help you build a solution that works
