Most teams ask for the wrong project.
They say "redesign" when they mean "rebuild." They say "rebuild" when they mean "redesign." The two words sound interchangeable. The projects behind them are not. A redesign is six weeks of visual work on top of working infrastructure. A rebuild is three to six months of replacing the infrastructure, with the visual work as a small piece of it.
Picking the wrong one is expensive. Pick redesign when you should have rebuilt and you'll ship a beautiful site that still loads in four seconds. Pick rebuild when a redesign would have done, and you've spent three months replacing code that worked.
This post is the framework we use to tell which project you're actually doing.
The definitions
Redesign. Visual and content work. The site's structure stays largely the same. The code stays. The CMS stays. What changes: typography, colour, layout, copy, maybe IA.
Rebuild. Code and infrastructure work. Often a different stack, different CMS, different hosting. The visual design might stay the same, might change a little, might be redone entirely. The platform underneath is the project.
Hybrid. A redesign of the visible site on top of a rebuild of the platform. This is more common than either pure option. It's the right answer when the visible site has identity problems and the platform has technical problems, and tackling them separately would mean two projects.
The signals for redesign
You probably need a redesign (not a rebuild) when:
The platform works fine. Lighthouse scores are decent, CMS is usable, deployments are routine. The team isn't avoiding touching the code. What's wrong is what the user sees.
The brand has shifted. New positioning, new audience, new tone. The site says one thing; the company says another. Visual and content fix what's broken.
The IA is outdated. Pages exist in the wrong places, navigation is wrong, conversion paths have been added and removed over time without cleanup. An IA-led redesign fixes most of this. See our post on IA for marketing sites for the method.
A specific section underperforms. Pricing page bounces are too high. The case studies section gets no traffic. The contact form has a 70% drop-off. Targeted redesign work, not a rebuild.
You'd describe the problem as "feels stale" or "doesn't reflect who we are now." These are visual and content problems.
The signals for rebuild
You probably need a rebuild (not a redesign) when:
The platform is the bottleneck. You can't add a customer login because the CMS doesn't support it. Adding a new page type takes a week because of how the templates are structured. Editors have to ping engineering for routine changes. The platform is in the way of the work.
Performance can't be fixed without rebuilding. The site is on WordPress with 47 plugins. Lighthouse scores are 30 and have been for two years. Every "performance improvement" is a band-aid. The fundamental architecture won't allow the performance you need.
The team can't ship on it. Engineers avoid touching the codebase. Bugs take days to fix. Onboarding a new developer takes a month. The platform is technical debt that's compounding.
Security or compliance is unsupportable. Old PHP, unmaintained dependencies, the original framework is end-of-life. You can't get to compliance from here without replacing the substrate.
You'd describe the problem as "we've outgrown this" or "we can't move fast on this." These are platform problems.
The hybrid signal
The hybrid pattern (redesign + rebuild simultaneously) is right when both lists above ring true. The platform is a problem AND the brand has shifted. The IA is outdated AND the CMS can't support a better IA. Performance is bad AND the visual design is also dated.
This is most common when a site is more than three or four years old. Brands shift, technology moves on, what was the right answer in 2022 isn't in 2026.
The hybrid is more expensive than either pure option. It's not 2x — there are real efficiencies in doing them together (IA work informs the new code structure; brand work informs the design system). But it's not a small project.
A redesign that should have been a rebuild
A team came to us a year ago. They wanted a redesign. Their site felt slow, the brand had shifted, conversion was bad. We almost took the redesign brief.
We ran the performance audit first. The findings:
- The site was on a legacy CMS the team was actively trying to replace.
- Page load times were 4-6 seconds and couldn't be fixed without leaving the CMS.
- Adding a new feature (a customer portal they wanted to launch in 2026) was impossible on the current platform.
- The brand redesign would have looked beautiful and still loaded slowly, still blocked the portal launch.
We pushed back. The right project was a rebuild that included redesign work. They'd been thinking redesign because redesign sounded smaller and less risky. The audit showed that "smaller" meant "wrong."
We did the hybrid. Took five months. The new site was faster, the customer portal launched on time, the brand work landed. If they'd done the redesign first, they'd have done the rebuild six months later anyway, with the redesign work to redo on top of the new platform. Net: nine months of work, two redesigns paid for, the rebuild still ahead of them.
Picking the right project first saved a year.
A rebuild that should have been a redesign
The opposite case: a team came to us wanting a full rebuild. The site was four years old. The team was sure it was the wrong stack, the wrong CMS, the wrong hosting.
We asked them to pick three specific problems the rebuild would solve. The list:
- "Page loads are slow." Audit: actually 1.8s LCP, which is fine. The CEO had been on a 2017 phone in a basement office.
- "The CMS is bad." Investigation: the CMS was Sanity, the team was using it through the wrong workflow. Two days of training would have fixed it.
- "We can't update the brand colour." Inspection: it was hardcoded in three places. A pull request would change them all in an hour.
None of these were platform problems. The team's frustration was real, but the cause wasn't what they thought. The rebuild would have been six months of replacing code that worked, ending in a site that had the same problems because the problems weren't in the code.
We did a one-week audit, a two-week targeted fix, and a four-week redesign of the visual identity. The team got most of what they wanted in seven weeks instead of six months. The original platform survived. Saved them three figures of engineering time and a quarter of velocity.
The framework
Three questions, in order:
- Can the platform support what you need to ship in the next 12 months?
- If no, you need a rebuild (or hybrid). - If yes, continue to 2.
- Is the team able to ship on the current code at a reasonable pace?
- If no, you need a rebuild (or hybrid). - If yes, continue to 3.
- Is the visible problem brand, IA, or content?
- If yes, you need a redesign. - If no, audit further. The "visible problem" might actually be a platform problem in disguise.
Most teams fail this at step 2. They've adapted to the slow pace and don't realise how much friction the platform is adding until they see what an unblocked pace looks like.
When to skip the framework
If the platform is end-of-life (the framework is unmaintained, the hosting is being deprecated, the CMS company is dead), you need a rebuild regardless of everything else. The market is forcing the timing.
Otherwise: don't skip the framework. The cost of picking wrong is enormous.
The conversation we have
When a client comes to us with "we need a redesign" or "we need a rebuild," our first job is to figure out which project they actually need. The conversation usually goes:
- What's the specific problem you want fixed?
- What have you tried? What did and didn't work?
- Show me the worst page.
- Show me what the editors do in a typical week.
- Show me what the engineers avoid touching.
By the end of this conversation we usually know which project is right. About 30% of the time the client agrees immediately. About 50% of the time they're surprised and need a day to think. About 20% of the time they push back, and we either accept their framing (they know their situation better than we do, sometimes) or part ways amicably.
If you're staring at "redesign or rebuild" and want a second opinion, start a conversation. We'll tell you honestly which project you're doing, and if it's not one we should do for you, we'll say that too.