A rebuild is the easiest thing in the world for an agency to sell — and one of the most expensive things you’ll ever buy. Before you sign off six figures and six months of waiting, here’s the test we apply to every platform that lands on our desk with a rebuild quote attached.
We get the same call several times a month. A business-critical platform is misbehaving — a checkout that won’t complete, an integration that’s stopped syncing, a site that buckles under traffic. The incumbent agency has looked at it, thrown up their hands, and delivered the verdict: it’s too far gone, you need a rebuild. Often with a number attached that starts at £50,000 and climbs from there.
Sometimes that verdict is right. Usually it isn’t. And the difference between the two is worth understanding before you commit, because a rebuild you didn’t need is one of the most avoidable costs in software.
Why rebuilds get recommended so often
It helps to be honest about the incentives. A rebuild is commercially attractive for an agency in a way that a fix simply isn’t:
- It’s a large, well-defined project with a clear scope and predictable revenue.
- It sidesteps the hard, unglamorous work of understanding someone else’s code.
- It resets the relationship — the agency now owns a codebase it built, on its terms.
None of that is necessarily cynical. Plenty of developers genuinely find it faster to start again than to read a messy, undocumented codebase and work out what’s actually wrong. But “faster for us” and “right for you” are not the same thing. A rebuild means you spend the money, wait the months, and operate with a compromised or frozen platform while the new one is built — all to solve a problem that frequently has a specific, diagnosable cause.
A rebuild recommendation tells you how the agency likes to work. It doesn’t tell you what your platform actually needs.
The test we apply before spending a penny
When a platform reaches us with a rebuild quote already on the table, we don’t accept or reject that quote on instinct. We run an assessment first — and the assessment is designed to answer one question: is there a specific, fixable root cause, or is the platform genuinely beyond economic repair?
1. Find the actual root cause, not the surface disorder
Most struggling platforms look alarming on the surface: years of plugin sprawl, inconsistent code, a database that’s been patched and re-patched. It’s tempting to conclude that the mess is the problem. It usually isn’t. Underneath the disorder there’s normally a specific origin for the failure — a version conflict, a broken integration, a single bad migration. We find that before we form any opinion on rebuilding.
2. Separate “messy” from “broken”
Technical debt and a critical fault are different things. A platform can be untidy and still be entirely fixable and maintainable. Tidiness can be improved incrementally, on your schedule, without downtime. A genuine architectural dead-end is rare — and it looks very different from “this code could be neater”.
3. Price the fix against the rebuild honestly
Only once we know the root cause can anyone put a fair number on the fix. In the overwhelming majority of cases, that number is a fraction of the rebuild — and it comes without the months of waiting or the risk of re-onboarding customers, migrating data, and discovering new bugs in brand-new code.
Case in point — My GSN
A multi-million-pound subscription platform had been down for six weeks. The incumbent agency couldn’t find the cause; a separate supplier quoted over £60,000 for a full rebuild. We took over the codebase, identified the root cause within 48 hours, and had it resolved in three days — no rebuild, no data loss, no disruption to existing subscribers. Read the full story →
When a rebuild genuinely is the answer
To be clear: sometimes it is. A platform built on a framework that’s reached end-of-life with no security support, an architecture that fundamentally can’t do what the business now needs, a codebase so entangled that every fix creates two new faults — these exist. We’ve seen them. But in 26 years, a genuinely necessary rebuild has been the rare exception, not the default recommendation. The honest position is to prove the fix isn’t viable before reaching for the rebuild, not the other way around.
Been told your platform needs a rebuild?
Get a second opinion first — a straight assessment of what it actually needs, before you spend anything.
Questions to ask before you approve a rebuild
If you’re staring at a rebuild quote right now, take it back to whoever wrote it with these:
- What is the specific root cause of the current problem? If they can’t name it, they haven’t found it — and a rebuild is a guess, not a diagnosis.
- What would it cost to fix that specific cause? You need both numbers to make a real decision, not just the big one.
- What happens to my data, my customers and my SEO during the rebuild? Migrations and re-launches carry real risk that a targeted fix avoids entirely.
- Who owns and supports the result? A rebuild that leaves you dependent on a single agency isn’t a fix — it’s a new dependency.
The fix-first principle isn’t about never rebuilding. It’s about refusing to spend your budget on the most expensive option until someone has proven the cheaper one won’t work. That’s the order we do it in — assess honestly, tell you what the platform actually needs, and explain exactly why, before we spend any of your money finding out.
Resolve Beyond is the specialist support partner behind business-critical platforms. We fix, maintain and improve the systems your business depends on — including the ones we didn’t build.
