Redesign or Rebuild? A Scoring Framework for Deciding What Your Website Actually Needs

"Does our website need a redesign?" is almost always the wrong first question. It assumes the answer is somewhere on a spectrum between "leave it alone" and "make it prettier." But a meaningful share of the websites we're asked to redesign don't actually have a design problem — they have a foundation problem, and no amount of new layout work will fix that underneath the surface.

The distinction matters because the two paths cost differently, take differently long, and solve different problems. A redesign keeps the underlying structure and changes what sits on top of it — layout, visuals, copy, UX flow. A rebuild replaces the foundation itself — the codebase, the content architecture, sometimes the platform. Pick the wrong one and you either overpay for a cosmetic fix that doesn't address the real issue, or you tear down something that didn't need to go.

The framework: ten questions, scored honestly

Answer each question below with a score of 0, 1, or 2, based on how closely it describes your current site. Add them up at the end.

What the score means

0–6: Tweak, don't touch the foundation

The underlying structure is sound. What's needed is targeted work — updated copy, a refreshed visual layer, fixed UX friction points, or a few new pages. A full redesign here risks spending budget on problems that don't exist while leaving the real, smaller issues unaddressed.

7–13: Redesign

The foundation is still workable, but what's built on top of it no longer reflects the business or performs the way it should. This is the sweet spot for a redesign — new UX, new visual system, often new content architecture, while keeping the platform and technical base that still functions.

14–20: Rebuild

Multiple structural issues are compounding — technical debt, platform ceilings, performance problems that resist surface fixes. At this score, a redesign tends to be a more expensive way of delaying a rebuild, not avoiding one. The visual layer isn't the bottleneck; the foundation is.

Why this gets decided wrong so often

Redesigns feel safer because they're visible and contained — new screens to approve, a clear before-and-after. Rebuilds feel riskier because much of the work is invisible until it's done. That asymmetry pushes businesses toward redesigns even when the scoring points toward a rebuild, because the smaller, more visible project is psychologically easier to greenlight.

The cost of that mismatch shows up later, not immediately. A redesign layered onto a foundation with real technical debt tends to look great at launch and then degrade quickly — the same maintenance friction, the same performance ceiling, now wrapped in a newer UI that makes the underlying problems harder to diagnose because everything "looks" fixed.

A redesign changes what visitors see. A rebuild changes what the business can do. Confusing the two is the most expensive mistake in this decision.

A middle path exists too

Not every rebuild has to happen all at once. Where budget or timing is tight, a phased approach — rebuilding the highest-friction parts of the foundation first, while redesigning the visual layer on a slightly longer timeline — can de-risk the decision without forcing a choice between "live with the problems" and "replace everything at once." The scoring framework above still applies; it just determines where the phased work starts.

The honest version of this advice doesn't always point toward the bigger project. Plenty of sites that come in for a "full rebuild" conversation score well under 7 — what they actually need is smaller, faster, and cheaper than assumed. The framework exists to catch both mistakes, not just one.