Website rebuild or repair? Our rubric before you spend

"Should we rebuild the website or just fix it?" is the most common question we're asked, and it's almost always asked with the answer already assumed. Someone is tired of looking at it.

Tiredness is not a rebuild trigger. Nor is age, nor a competitor's shiny new homepage, nor a red score in a sales email. The honest test is narrow, and most sites fail it — meaning most sites should be repaired, not replaced.

Here's the rubric we run, why each rule is worded the way it is, and how to score your own site in about an hour.

Why most rebuild decisions are made badly

Three forces push toward rebuilding regardless of merit.

Rebuilds are easier to sell. A rebuild is a project with a number, a timeline and a launch. A repair programme is a series of unglamorous fixes with no announcement at the end. Guess which one an agency proposes.

Dissatisfaction has no natural resolution. When a site underperforms, nobody can point to the cause, so "start over" becomes the answer that feels like action. It isn't a diagnosis; it's an escape from having to make one.

The wrong evidence is easy to gather. A speed score, a screenshot on a phone, a competitor comparison. All easy, none diagnostic. We've written about why a single performance score can't support a decision like this — the same unchanged page can score 33 and 99 within a month.

The consequence: businesses rebuild, spend a quarter, launch something that looks better, and discover the underlying problem is still there — because the problem was the content, the offer, the intake, or the fact that nobody has published anything in two years.

The five triggers

A rebuild is justified when at least one of these is true. Not "would be nice to fix" — genuinely true.

1. You cannot safely change it. No source code, no working deploy path, a theme edited directly in production, or a codebase so fragile nobody will touch it. If shipping a change is dangerous, everything downstream is blocked and repair has no path.

2. The platform structurally can't do what the business needs. (Which platform suits which constraint is its own question.) You've started selling and there's no real commerce. You need multiple languages and there's no sane way. Not "it's awkward" — cannot, without a workaround you'd then maintain forever.

3. The structure can't express what you sell. The site says you're a photographer; you now run a studio with four service lines. Information architecture is the hardest thing to retrofit, and a site organised around a business you no longer run will keep fighting you.

4. Nobody but a developer can publish. If every copy change is a ticket, the site will ossify. This one is worth rebuilding for on its own, because it compounds — the cost isn't the tickets, it's everything nobody bothered to ask for.

5. The technical debt exceeds the rebuild cost. Rare and genuinely quantifiable: a codebase where each change costs multiples of what it should. Reach for this one carefully, because "it's messy" is not the same as "it's cheaper to start over."

Notice what isn't on the list: appearance, speed, conversion rate, mobile layout, and the words. All four are repairs, usually cheaper ones than people assume.

Run it in this order

The sequence matters, because a yes at step one makes the rest irrelevant. And note that none of the questions is "does it look old" — that's a design refresh, and a design refresh on an existing platform is a fraction of the cost and risk of a rebuild.

A scoring rubric you can run yourself

Score each row honestly. Any single rebuild answer in the first block justifies the conversation; two or more makes it near-certain.

And the rows that look like rebuild reasons and aren't:

That second table is where most of the money gets saved. A site that converts badly will usually convert badly after a rebuild too, because conversion is a function of offer, proof and friction — not framework.

On measuring the technical side honestly

If you're going to use measurements to support the decision, use ones that mean something.

Don't rely on a single performance score. It moves substantially run to run on an unchanged page. If you're going to use it, take the median of several runs, and treat anything under a ten-point difference as noise.

Don't use total page weight as evidence of bad engineering. This is the trap we had to correct in our own scoring: total bytes are overwhelmingly images — the content a site exists to show. A photography portfolio is heavy because it's a photography portfolio. Weighing total bytes measures the subject matter, not how the site was built.

Do look at script weight specifically. JavaScript transfer size is a far better proxy for architectural bloat, because scripts are what a build adds rather than what a business publishes. A marketing site shipping several megabytes of script has an architecture problem; the same site shipping several megabytes of images may simply have a lot to show.

Do look at what a change costs. Not a metric a tool reports — ask your developer how long a specific small change takes, and whether they're confident nothing else will break. That answer is more diagnostic than any score.

Do look at the editing path. Log in and try to publish something. If you can't work out how in ten minutes, neither can the person you'll hire next year.

We calibrated our own thresholds against a set of sites we already knew were well built and a set we knew weren't. That exercise is worth doing before trusting any rule: a threshold that flags known-good sites is measuring the wrong thing, however sensible it looked when you wrote it.

The repair programme nobody proposes

If the rubric says repair, here's the order that produces the most return, roughly by value per unit of effort:

1. Fix the intake. Shorter forms, tested end to end, routed to a person, with a response-time commitment. This is nearly always the cheapest meaningful win available.
2. Fix the top five pages' copy. Not the whole site — the five pages that get traffic. Say what you do, for whom, and what happens next.
3. Fix the obvious speed problems. Oversized images, unused scripts, render-blocking fonts. Diagnose properly rather than chasing a score.
4. Fix mobile layout on the pages that matter. Most traffic, least attention.
5. Add the pages that are missing. Usually a service or practice area you sell but never wrote a page about.
6. Fix internal linking. Large sites routinely have valuable pages nothing links to.
7. Then, if it's still needed, redesign the front end on the same platform, keeping the URLs.

Step seven is the point people wanted to start at. Reaching it having done one through six means you redesign knowing what actually needed changing — and quite often, by the time you get there, the pressure has gone, because the site started working.

When a "rebuild" is really a re-platform

Worth separating, because they're priced very differently.

A redesign changes how it looks. Same platform, same URLs, same content — new templates and visual system. Weeks. Low risk.

A restructure changes how it's organised. New information architecture, new page types, redirects for anything that moves. Weeks to a couple of months. Moderate risk, mostly in redirects.

A re-platform changes the underlying system. Everything is rebuilt, content migrates, every URL is remapped, tracking is re-implemented. Months. Highest risk, and the only one of the three that should be triggered by the five rules above.

Most requests that arrive as "we need a rebuild" are satisfied by a redesign plus a restructure — and those two can be done incrementally, on the platform you already have, without a launch date that everything else waits behind.

What a rebuild actually costs you, beyond the invoice

The quoted price is the smallest part of a rebuild's cost, which is why the decision deserves more rigour than it usually gets.

Organisational attention. A rebuild consumes senior time for its whole duration — approvals, content, decisions, reviews. That's time not spent selling. On small teams this is the largest real cost and it never appears on a proposal.

A publishing freeze. Most organisations stop improving the current site once a replacement is coming. Three to six months of not fixing, not publishing, not testing — usually at exactly the moment someone has finally decided the website matters.

Ranking risk. Every URL that moves is a chance to lose position. Well-managed, the risk is small. Managed by someone who thinks redirects are a launch-day task, it isn't.

Loss of accumulated tuning. The current site contains years of small corrections nobody documented — a form field that was removed because it confused people, a heading rewritten after complaints. Rebuilds routinely reintroduce solved problems because nobody recorded that they were solved.

Restart of measurement. New pages, new events, new baselines. Any before-and-after comparison gets murky for a quarter.

None of this argues against rebuilding when a rebuild is warranted. It argues for being sure, because these costs are paid whether or not the rebuild was the right call.

The evidence worth gathering before the meeting

If a rebuild is genuinely on the table, an afternoon of evidence beats a month of opinion. Six things to collect, none requiring specialist tooling:

A full URL inventory. Crawl the site and count what exists. Businesses are routinely wrong about their own size by an order of magnitude — a firm that thinks it has forty pages often has four hundred, most of them forgotten. This number alone changes the shape of the project, because every one of those URLs has to be decided about.

Your top twenty pages by traffic. From analytics, over twelve months. These are the pages a rebuild must not break, and they're frequently not the ones anyone expects. The homepage is rarely the whole story; often an old blog post nobody remembers is bringing in a quarter of the traffic.

The pages with links pointing at them. Any backlink tool will do. Pages that other sites reference are the ones with accumulated authority, and losing or redirecting them carelessly is the most expensive single mistake available in a rebuild.

What people actually do on the site. Where enquiries come from, which pages precede them. If you don't know, that's a finding in itself — and worth fixing before spending on anything else, because you're about to make a large decision blind.

An honest list of what nobody has done. Content not published, pages not written, forms not tested, fixes deferred. If that list is long, the site's problem is probably neglect rather than architecture, and a rebuild will inherit the neglect.

The change-cost answer. Ask your developer, in writing: how long does a small change take, and what are you worried about when you make one? Their answer is the single most diagnostic piece of evidence available, and it's free.

With those six in hand, the rebuild-or-repair conversation takes about twenty minutes and rarely produces disagreement. Without them, it takes weeks and gets settled by whoever is most confident in the room — which is exactly the failure mode this rubric exists to prevent.

One more thing worth doing before deciding: look at what your best-performing pages have in common. Often it's not design at all. It's that someone answered a real question properly on that page, years ago, and nobody has done it since. If that's the pattern, the intervention isn't a rebuild — it's doing that again, deliberately, ten more times.

Two questions that settle most cases

When we're asked to arbitrate, two questions usually resolve it in the first ten minutes.

"What will the new site do that the current one cannot?"

Insist on specifics. "Look more modern" is not a capability. "Let our team publish case studies without a developer," "support French," "sell online" — those are capabilities, and each maps to a trigger above. If the answer stays vague under pressure, the honest conclusion is that nobody has diagnosed anything yet, and a rebuild will be an expensive way to avoid doing so.

"What have you tried?"

If the answer is nothing — no copy changes, no intake test, no speed work, nothing published in a year — a rebuild is being used to substitute for work that will still be needed afterwards. The new site will launch, the same neglect will resume, and in three years the same conversation happens about the site being tired.

A site is not a product you buy. It's a thing you operate. The strongest predictor of whether a rebuild pays off isn't the quality of the build — it's whether anybody is going to look after it afterwards. A modest site that someone actively maintains beats an excellent one nobody touches, every time, and if the answer to "who owns this after launch" is a shrug, that problem should be solved before any money is spent on design.

The one-hour version

If you want the short diagnostic:

1. Ask your developer to make one small change and tell you how long it took and what they were worried about.
2. Log in and try to publish a page yourself.
3. List the three things the business sells that the site doesn't have a page for.
4. Open your top five pages on your phone.
5. Submit your own contact form and see what happens, and how fast.

If steps one and two go badly, you have a rebuild conversation. If they go fine and steps three to five go badly, you have a repair list — and it's shorter and cheaper than the rebuild you were about to commission.

If you'd like a second opinion before committing a budget, send us the URL. We'll run the rubric and tell you which one it is, including the frequent case where the answer is that your site is fine and something else needs the money.

Keep reading

• Claude Code 2026: AI website development from the CLI
• OLVR ring scroll: Rolex 3D via Shopify custom development

Work with Rough Works

Need a partner for your next site? We're a Vancouver-based digital agency building websites and AI-enhanced experiences for brands across Canada and the United States. Start a project →