Most technology rebuilds I get asked to evaluate follow the same script. Leadership believes the platform has become old, slow, or fragile, and the engineering team is pushing for a rewrite. By the time I am in the room, the rewrite has usually already been framed as inevitable, and my job is treated as validating the timeline rather than questioning the premise.
When I actually dig into the platform itself, it is usually still fine for the business it was originally built to serve. The problem is that the business is no longer that business. A company that once sold to small teams is now closing enterprise contracts. A product that once had a single integration point now needs to support a dozen partner systems nobody designed for on day one. The platform did not age in the way people describe it. The business model outgrew the assumptions baked into the platform years earlier, quietly, one contract at a time.
Rewriting the code without first rewriting those assumptions produces a newer version of the same mismatch, just with fresher syntax. I have seen companies spend eighteen months and a meaningful chunk of their engineering budget on a rebuild that recreated the exact same limitations, because nobody stopped to ask what the business actually sells today compared to three years ago before the first line of new code was written.
The Question That Should Come Before Any Rebuild
Before I let a client commit engineering resources to a platform rebuild, I ask one question that is rarely asked in the room where the rebuild gets approved: what does this business sell today, in concrete terms, compared to what it sold when this platform was designed. Not the mission statement. The actual revenue mix, the actual customer segment, the actual contracts on the books right now.
That answer usually tells you more about what needs to change than any architecture review. If the revenue mix has shifted from self-serve small business customers to negotiated enterprise contracts, the platform’s original assumptions about user provisioning, data isolation, and support workflows are probably wrong at a structural level, and no amount of refactoring the existing code base will fix a structural mismatch. If the revenue mix has not meaningfully shifted, the platform may genuinely be technically behind, and a more conventional modernisation effort is the right call.
A Rebuild I Stopped Before It Started
A client came to me convinced their core platform needed a full rewrite because performance had degraded and the engineering team was frustrated with the existing architecture. Before approving any scope, we mapped their last three years of contracts against the platform’s original design assumptions. The pattern was immediate. Every new enterprise contract required custom data handling the platform had never been designed to support, and engineers were bolting workarounds onto workarounds to keep closing deals.
The fix was not a rewrite. It was a deliberate, scoped redesign of exactly the subsystems that no longer matched what the business actually sold, while leaving the parts of the platform that still served the original small business customers untouched. That approach cost a fraction of a full rebuild and shipped in under four months, because the team was solving the actual mismatch rather than rewriting code that was never the real problem.
Most leaders who have run this calculation are surprised by where the real cost sits.
Why Engineering Teams Rarely Catch This on Their Own
This is not a failure of the engineering team’s competence. Engineers are, correctly, focused on the code in front of them, and code that has accumulated years of workarounds genuinely does become harder to maintain regardless of the underlying business reason. The frustration engineers feel with a struggling platform is real and valid. But frustration with the code is not the same diagnostic as a mismatch between the platform’s assumptions and the business’s current model, and only someone looking at both the technology and the revenue mix together is positioned to tell the two apart.
This is precisely the gap a fractional technology leader is positioned to close, because the role sits deliberately between the engineering team’s view of the code and the executive team’s view of the business. Neither view alone reliably catches a platform mismatch before it turns into a multi-year rebuild that repeats the original problem in a new codebase.
What to Check Before You Approve the Next Rebuild
If a rebuild is being proposed inside your organisation right now, ask for a plain answer to what the business sells today versus three years ago, in the same document as the technical rationale for the rewrite. If the two documents tell different stories, that gap is worth resolving before a single sprint is planned. A rebuild that fixes the code without addressing the mismatch is expensive in a way that rarely shows up until eighteen months in, when the new platform starts accumulating the exact same workarounds the old one had.
The gap between a full-time CTO and a Fractional one is rarely what organisations expect before they see the numbers.
