Project delivery
Why the most important phase of development happens before development
The most expensive mistakes in web projects happen before a line of code is written. Here's what pre-build discovery actually looks like ...
The Blog
When to rebuild your website platform (and when to resist)
Project deliveryHeadless CMS
The conversation about rebuilding a platform usually starts with frustration. The site is slow. The CMS is painful. The design feels dated. New features take too long. Someone says "we should just start fresh" and suddenly there's a proposal on the table for a six-figure rebuild.
Sometimes that rebuild is exactly the right move. Sometimes it's a $80,000 solution to a $15,000 problem. The hard part is telling the difference, and being honest about which one you're looking at.
The signals
When a rebuild is actually warranted
Not every frustration with a platform means it needs replacing. But there are four signals that point to a genuine structural problem, not just a bad week.
- 01The architecture can't support what you need
The CMS doesn't model your content properly. You're working around fundamental limitations, using tags as categories, cramming structured data into rich text fields, building relationships with manual cross-references. The content model can't be fixed without starting over because the platform doesn't support the structures you need.
- 02Performance has a structural ceiling
You've optimised images, added caching, cleaned up scripts, and the site is still slow. The performance problems are architectural: server-side rendering that can't be decoupled, a theme layer that loads everything on every page, or a database structure that slows down as content grows. These aren't fixable with optimisation passes.
- 03The cost of maintenance exceeds the cost of rebuilding
You're spending more time maintaining the current platform than it would cost to build a replacement. Plugin conflicts, security patches that break features, custom workarounds that need constant attention. At some point the cumulative maintenance cost overtakes the one-time rebuild cost.
- 04The platform blocks your business strategy
You need to deliver content across multiple channels and the CMS only serves a website. You need editorial workflows for a growing team and the CMS doesn't support them. You need custom integrations and the platform's API is limited or nonexistent. The platform is a ceiling on what the business can do.
The alternatives
When a rebuild isn't the answer
A rebuild carries real risk, new platforms take time to stabilise, teams need onboarding, and you lose institutional knowledge baked into the current system. Before committing, rule these out first.
- 01The problem is content, not technology
A site can feel broken when the real issue is that the content hasn't been updated in two years. Before rebuilding the platform, audit the content. If the same pages with fresh, well-structured content would solve the problem, the platform isn't the issue.
- 02The problem is specific and fixable
A slow page doesn't mean the whole site needs rebuilding. A painful editing experience might be solved by CMS configuration changes. An outdated design can be refreshed without changing the underlying architecture. Targeted fixes are cheaper, faster, and lower risk.
- 03The team isn't ready for the change
A new platform is only as good as the team that uses it. If the content team is struggling with the current CMS, a more complex headless CMS with more flexibility might make things worse unless there's a proper onboarding plan. The platform should match the team's capacity.
- 04There's no clear scope
"We need a rebuild" without defined requirements is how projects go over budget. If you can't articulate what the new platform needs to do differently, not just "be better", the rebuild isn't ready to start. Discovery should come before commitment.
The diagnosis
How to tell which one you're looking at
The honest test is to list every problem with the current platform and ask two questions about each one: "Is this fixable on the current platform?" and "What would fixing it cost versus rebuilding?"
Some problems are genuinely structural. If your CMS can't model content relationships, no amount of configuration will fix that. If your frontend architecture has a performance ceiling, optimisation won't break through it.
But many problems that feel structural are actually operational. Content that's out of date. Editorial processes that haven't been set up properly. Features that exist in the platform but haven't been configured. These are cheaper to fix than to rebuild around.
The rebuild conversation should happen after the diagnosis, not instead of it.
The case
Making the case internally for a rebuild (or against one)
Once you've diagnosed whether a rebuild is warranted, you still need to get buy-in. Decision-makers don't respond to frustration, they respond to cost and capability.
- 01Quantify the current cost
Maintenance hours, lost opportunities, workarounds, developer time on patches. Decision-makers respond to ongoing cost, not frustration. "We spend $X per month maintaining a platform that limits our ability to do Y" is a stronger argument than "the site feels old."
- 02Define what the new platform needs to do differently
Not a feature list, a capabilities gap. What can't you do today that the business needs? Multi-channel content delivery, structured editorial workflows, custom integrations, performance targets. These justify the investment in concrete terms.
- 03Present the alternatives honestly
Sometimes the right recommendation is "don't rebuild." Targeted improvements at a fraction of the cost might solve the actual problems. Presenting this option builds credibility, and if the rebuild is genuinely the right move, the comparison makes the case stronger.