Redesign versus incremental fixes

Ask a marketing director why their company just spent eight months and a serious budget on a new website, and the honest ones will eventually admit the real reason: it was easier to get approved. Not cheaper. Not lower-risk. Easier to approve, because a rebuild is one decision — sign one contract, review one set of mockups, cut one ribbon — while the alternative is asking for sign-off on fifty small things over a year, half of which sound too minor to justify a meeting.

That is the honest starting point, because the case for incremental fixes only holds up if you concede this first: a rebuild is genuinely the path of least organisational resistance, and treating that as pure irrationality misses what's actually happening. A single invoice with a clear before-and-after is something a board can evaluate in one sitting. A fixes programme is a subscription to ongoing judgment calls, and most organisations are worse at sustaining ongoing judgment than they are at approving a one-time expense.

With that conceded: in nearly every case where the underlying platform still functions, incremental fixes beat a full rebuild on expected value, and the gap is not close. The reason firms keep choosing the worse option anyway is organisational, not analytical — and once you see the mechanism, it's worth designing around rather than just naming.

What a rebuild deletes along with what it fixes

A website that has been live for two or three years is not just a stack of pages. It is a record of thousands of small experiments nobody wrote down as experiments. Some headline on the pricing page has been sitting there long enough that Google has decided how much to trust it. Some paragraph on the about page has quietly become the one prospects mention on discovery calls. Some product page ranks third for a term that took eighteen months to earn, through a combination of links, dwell time and relevance signals that no one can fully reconstruct after the fact.

None of that is documented anywhere a new build inherits automatically. It exists only as the shape of the current site. A rebuild that replaces the templates, the URLs and the copy in one motion doesn't just fix what was broken — it also discards whatever had quietly started working, and there's no way to sort the two in advance, because the team commissioning the rebuild usually doesn't know which of its own pages are carrying weight until after they're gone. A fixes programme has the opposite property almost by construction: because it touches one page or one flow at a time, everything it doesn't touch keeps whatever it had already earned.

The arithmetic, twelve months against one rebuild

Put rough numbers next to both paths and the comparison stops being a matter of taste.

	Full rebuild	Twelve-month fixes programme
Typical spend	One large budget, committed up front	A series of smaller budgets, committed as evidence justifies each one
Time to any improvement	Nothing ships until the whole site does — commonly six to twelve months	The first fix can ship within weeks of diagnosis
Risk if the diagnosis was wrong	The whole budget is spent before anyone finds out	Only the current fix is wasted; the next one can correct course
Accumulated SEO and conversion learning	Reset, with a recovery period before it's clear whether the reset was worth it	Preserved everywhere the programme hasn't touched
What happens if the project stalls	A half-built new site, with the old one often already partly decommissioned	Whatever shipped so far stays live and useful on its own

The row that matters most is the third one. A rebuild is a single large bet that only reveals whether the underlying diagnosis was correct after the money is already spent. A fixes programme is a sequence of small bets, each one informative before the next is placed. If the first fix to the pricing page doesn't move the drop-off rate, that's a signal to change the hypothesis before spending on the second fix — a kind of course-correction a rebuild structurally cannot offer, because by the time you can measure whether the new homepage converts better, the homepage, the navigation and the content model have all changed at once, and there's no way to tell which change did what.

None of this means fixes are free or that a rebuild never pays for itself. It means the rebuild has to clear a higher bar than "the current site has problems," because a fixes programme addresses most of the same problems at a fraction of the cost and with the option to stop.

Why the worse option keeps winning budget

If the arithmetic favours fixes this clearly, the interesting question isn't which option is better — it's why organisations keep choosing the other one, and the answer is almost entirely about how each option is governed rather than what each one costs.

A rebuild has a start date, an end date, a named vendor or team, and a deliverable everyone can see. It fits inside a single budget cycle and a single approval, and produces a status meeting where there's something to look at — mockups, then a staging site, then a launch. Every part of that is legible to an organisation that reviews projects in quarterly cycles and wants a clean line between "before" and "after."

A fixes programme has none of that shape by default. It's fifty decisions spread across a year, each one small enough that it doesn't clear the threshold for a formal proposal, which means each one either gets made informally — by whoever is loudest in the room that week — or doesn't get made at all because nobody owns the calendar. The individual fixes are cheap and low-risk, which is exactly why they're easy to defer indefinitely: there's no forcing function, no fixed date by which the pricing page redesign has to happen, so it slides to next quarter and then the quarter after that. That's the actual failure mode of incremental work, and it's worth naming precisely because it's fixable — fixes rarely get the governance a rebuild receives automatically, and without it a fixes programme dies of ordinary neglect rather than of being the wrong strategy.

Running a fixes programme so month four doesn't kill it

Treat the programme with the same seriousness a rebuild gets by contract, because nothing else will impose that seriousness on it.

Give it a single owner who is accountable for the roadmap the way a project manager is accountable for a rebuild's timeline — not a committee, one person whose job includes making sure the backlog moves. Rank the backlog by the evidence that justified the programme in the first place, not by whoever raised their fix most recently in a meeting; a drop-off on the checkout page that's costing revenue every week outranks a stakeholder's pet page regardless of who's asking. Fix a cadence — monthly is common — so there's a recurring date by which something ships. And measure each fix against the number that justified it: if the pricing page fix was meant to close a drop-off gap, check whether the gap closed before moving to the next item.

The programmes that stall at month three are almost always the ones missing one of those four things — usually the owner, because "everyone" being responsible for the backlog means no one is.

Where the arithmetic actually flips

The case for fixes over a rebuild depends entirely on the platform still being able to do the job, and there are real situations where it can't.

The platform itself is reaching end of life. If the vendor behind the CMS has announced deprecation, or the underlying software has stopped receiving security updates, a fixes programme is patching a foundation that's being condemned regardless of how well the patches work. Here the comparison isn't really against fixes — it's against the cost of staying on unsupported infrastructure, which tends to be higher than either option once a breach or an outage is priced in.

The content model cannot express what the business now sells. A site built with templates for one product line doesn't bend to add a second one, a services arm, or a shift from selling a tool to selling a platform. This is a structural limit, not a styling problem, and no amount of page-by-page fixing gets around a content type the CMS schema has no field for. The fuller version of how to tell this trigger apart from a cosmetic complaint is covered in the redesign decision — most requests that sound structural turn out, on inspection, to be aesthetic.

A legal or accessibility obligation the current site cannot meet. If an accessibility audit finds the underlying template architecture, not individual pages, is the barrier to compliance, or a data-handling requirement demands infrastructure the platform was never built to support, that's an obligation with a deadline attached, and incremental fixes to individual pages won't satisfy an auditor who's evaluating the platform.

Each of those is a real trigger with real evidence behind it, and each is rarer in practice than the volume of rebuild requests would suggest. Most sites that get rebuilt clear none of these three bars — they clear the much lower bar of "someone senior thinks it looks tired," a real feeling and a bad reason to spend a rebuild's budget on a fixes problem.

The recommendation, and what it depends on

Default to fixes. Run the diagnosis first — the funnel data, the session recordings, the support tickets — and let it tell you whether you're looking at one of the three genuine rebuild triggers or a long list of smaller problems a fixes programme handles better and cheaper. If it's the latter, resist the pull toward a rebuild because it's easier to get approved; that ease is a fact about your organisation's governance, not a fact about which option serves the business.

If a rebuild is genuinely warranted, the choice of who runs it — an agency, an in-house team, or a freelancer — changes the cost and risk profile considerably, and that comparison is covered separately in agency versus in-house versus freelancer. And if the rebuild proceeds, the search authority this piece has been arguing is worth protecting doesn't have to be sacrificed wholesale — there's a real difference between a rebuild that resets rankings by accident and one that migrates them deliberately, the whole subject of replatforming without losing rankings.

The organisations that get this right aren't the ones with the strongest opinions about design trends. They're the ones willing to run fifty small, unglamorous, well-governed decisions instead of one large, satisfying one — because the arithmetic, run honestly, keeps landing on the boring answer.