The web design industry has a redesign habit. Every three to four years, businesses go through the same cycle: brief an agency, argue about the homepage for two months, launch something that looks fresh, and watch it gradually decay until the next redesign. We got tired of being part of that cycle.
The redesign cycle (and why it keeps repeating)
You know the pattern. The website is looking a bit dated. Someone in leadership says "we need a refresh." An agency gets briefed, mood boards appear, there are six rounds of feedback on the hero banner, and eventually a shiny new site goes live. Everyone's pleased for about six months. Then the small compromises start to surface.
The CMS is still the same WordPress install from 2018, now running 40-odd plugins that haven't been updated since the last developer touched them. The mobile experience was bolted on after the desktop version was signed off, so it works but never quite feels right. The page builder that seemed flexible at launch has become a straightjacket, because every new section needs a developer to wrangle it into shape.
A redesign gives you a new coat of paint on the same foundation. You can rearrange the furniture, but the house still has the same plumbing. And plumbing, eventually, is what lets you down.
What we mean by rebuilding
Rebuilding is a fundamentally different starting point. Instead of asking "what should the new site look like?" we ask "what does this website actually need to do?" Not what pages it should have, but what jobs it performs. Who uses it, and how? Where does the content come from? What needs to change frequently, and who should be able to change it without filing a support ticket?
A rebuild starts with questions about data flow, content management, performance requirements, and growth plans. A redesign starts with a mood board. Both have their place, but they solve very different problems. A redesign assumes the foundations are sound and the surface needs updating. A rebuild questions the foundations themselves.
In practical terms, that means we're choosing the right technology stack for the job rather than defaulting to what's familiar. We're treating content as structured data rather than blobs of text pasted into a page builder. And we're designing for how the site needs to perform in two years, not just how it needs to look on launch day.
- Your CMS fights you more than it helps you
- Page load times have crept past three seconds
- Adding a new section or feature requires a developer
- You've outgrown your original site structure but keep patching around it
- Your mobile experience feels like an afterthought
- Third-party plugins are doing jobs that should be core functionality
The uncomfortable conversation about technical debt
Most websites accumulate technical debt silently. Every quick fix, every plugin workaround, every "we'll sort that out later" adds to a hidden cost that nobody tracks. The contact form plugin that conflicts with the caching plugin. The custom CSS overrides stacked three layers deep because the theme wouldn't cooperate. The analytics script that loads four other scripts that nobody asked for.
By the time you're three years into a site's life, it's running on patches and good intentions. Performance has degraded gradually enough that nobody noticed the load time creeping from 1.2 seconds to 3.8. The admin interface is cluttered with settings for features you stopped using two years ago. Security updates feel like a game of whack-a-mole.
A redesign papers over all of this. The new theme goes on top of the same bloated foundation, and within a year you're back where you started. A rebuild deals with it properly. You start with a clean slate, carry forward only what's genuinely needed, and make deliberate choices about every dependency.
What a rebuild actually looks like in practice
Our rebuild process starts with discovery, and not the kind where we ask you to fill in a questionnaire about your favourite colours. We want to understand the business: what's working, what's painful, where you're heading in the next two to three years, and what the website needs to do to support that. This phase usually surfaces problems that nobody mentioned in the brief, because they'd stopped thinking of them as problems and started thinking of them as normal.
From there, we make architecture decisions. What's the right stack for this particular job? Sometimes that's a headless CMS with a modern frontend framework. Sometimes it's something more straightforward. The point is that we choose based on requirements, not habit. We've seen too many projects default to WordPress simply because the last agency used it, regardless of whether it was the right fit.
Content strategy comes next, and this is where rebuilds diverge most sharply from redesigns. We treat content as structured data. Instead of pages full of free-form text blocks, we model the content so it can be reused, filtered, translated, and rendered in different contexts. This is what makes a site genuinely flexible rather than just visually flexible.
Performance is a core requirement throughout, not something we optimise for after launch. And launch itself is the start of the process, not the end. A rebuilt site is designed to evolve. New sections, new features, new content types: these should be additions, not renovations.
When a redesign genuinely is the right call
We'd be doing you a disservice if we pretended every website needs rebuilding from scratch. That's not the case. If your brand has evolved and the visual identity needs refreshing, but the underlying technology is solid and performing well, a redesign is perfectly sensible. If the content structure works and your team can manage it without friction, there's no reason to tear it all down.
The key is being honest about which situation you're actually in. It's tempting to treat symptoms rather than causes, because a redesign feels more tangible and the results are immediately visible. But if the problems are structural, a fresh lick of paint will only hide them for so long. A good agency (us or otherwise) should be willing to tell you that a redesign is all you need, even when a rebuild would be more profitable for them.
The bit about budgets
Let's address the elephant in the room. Yes, a rebuild costs more upfront than a redesign. Sometimes significantly more. That's the number most people fixate on, and it's understandable. But it's also incomplete.
Consider the three-year cost of each option. A redesign that you'll need to redo in 2029, plus the ongoing costs of plugin licences, developer time for workarounds, performance optimisation patches, security firefighting, and the growing frustration of a team fighting their own tools. Compare that to a rebuild that's designed to grow with you, where adding new functionality is straightforward and the technology actively supports your team instead of slowing them down.
When you look at the total cost of ownership rather than just the initial invoice, the numbers start to tell a different story. We've had clients where the three-year cost of a rebuild was actually lower than the alternative, once you factored in everything the redesign-and-maintain approach was quietly costing them.
We're not on a crusade against redesigns. They have their place, and we still do them when they're the right answer. But we've learned, over years of building and maintaining websites for businesses of all sizes, that the redesign cycle often treats symptoms while ignoring the underlying condition. If you're about to kick off a website project, it's worth spending an hour asking whether you need a new look or a new foundation. The answer might save you a lot of time and money over the next few years.