Almost every growing organisation hits the same wall. Leadership wants to ship new capability to keep customers interested and win new business, but the service is standing on foundations that can barely support what’s already there.
The natural response is to compromise: build the new thing on top of what’s already fragile. In my experience that rarely works. You spend your time patching edge cases, delivery slows everywhere, and the experience gets worse at both ends, the old and the new.
This tension isn’t unique to any one company, and plenty of people have argued both sides of it. What I can offer is what actually happened when I sat on each side of that choice.
The pull in three directions
The tension usually comes down to three groups pulling against each other:
- · Leadership sees speed and growth. New features win deals and signal momentum, so pausing to fix the foundations can feel like standing still.
- · Product and design carry the daily friction. They want to ship something good, but old technology turns a simple change into a complicated one.
- · Engineering can get stuck between two right answers. Even when everyone agrees the foundation needs work, it’s easy for a team to spend weeks debating the ideal architecture instead of picking a workable one and building it.
When leadership pushes for innovation without allowing time to fix the base, and the team gets stuck debating the ideal fix, what’s left is a pile of mismatched pieces held together by workarounds.
Patching versus replacing
On one product I worked on, the plan was to keep innovating directly on top of an old system. The intent was reasonable: keep moving without stopping to rebuild. But it meant every new feature was also a fight against the legacy code underneath it, and that friction showed up as delays and fragile releases.
On another, at NetEDI, we took the harder route and replaced the legacy platform outright, rather than layering new features on top of it. That work is the NetIX Redesign and Rebrand case study. Once the team was on a single, clean foundation, feedback came back faster, the core platform improved without maintaining two competing systems, and new features actually shipped quicker, because they weren’t fighting old code to get there.
The hidden cost of “no downtime”
Refusing to invest in the foundations because there’s no time is a false economy. Build on something brittle for long enough, and:
- · Delivery slows down: what should take two weeks takes two months, because the team is fighting old constraints
- · Quality slips at both ends: new things don’t work as well as they could, and old things break in ways nobody expects
- · Trust erodes: people don’t care about the roadmap if the tool they use every day feels unreliable
Finding the pragmatic middle ground
Leadership will rarely grant six months to rewrite everything, and usually they shouldn’t. The answer is in how the foundational work gets framed and structured:
- · Replace, don’t layer: when a part of a system has hit its limit, replace that part properly rather than wrapping it in another workaround
- · Pick good enough over perfect: the aim isn’t the ideal architecture, it’s a solid pattern the team can actually ship
- · Frame it in terms leadership can act on: cost, risk and outcome, not just tidiness
If you want a service that feels new, you can’t build it on foundations that are falling apart.
The real work of design and product strategy isn’t only deciding what to build next. It’s making the case for fixing what’s already there, first.