"We don't know if we need a rebuild or just better people on it."

We hear some version of that line a lot. A website that used to be easy to change now needs 3 quotes for every update.

An app that shipped features every fortnight now ships them every quarter, if at all. Someone in the room says the whole thing needs starting again. Someone else says that's what the last agency said.

Deciding whether to rebuild or refactor is one of the most expensive calls a business makes about its tech, and it's often made on gut feel.

The problem is that "rebuild or refactor?" is really 3 questions tangled together. Is the code holding you back? Is the platform holding you back? Or is the team working on it the real issue?

Get those apart and the answer tends to become obvious. This guide shows you how to separate them, what triggers a genuine rebuild for e-commerce brands and digital products, and how long each route takes on real projects we've delivered.

Rebuild or refactor: what's the actual difference?

A refactor improves what you already have without changing what it does. A rebuild replaces it with something new. There's also a third option people forget: replatforming, where you move to a different platform (say, from a custom build to Shopify) and rebuild on top of it.

When people compare a website rebuild vs refactor, this is how the 3 routes stack up:

• Refactor: You tidy, restructure and modernise the existing code. Customers barely notice. Risk is low because you change things in small steps and keep shipping. Best when the foundations are sound but the build has got messy.
• Rebuild: You start again on the same or a modern stack. Risk is higher because nothing new goes live until a lot of work is done. Best when the structure itself is wrong, not just the details.
• Replatform: You move to a different platform and rebuild there. You inherit that platform's strengths and its rules. Best when the platform can't do what the business now needs.

A refactor is the cautious choice and usually the right first move. A rebuild is the bold choice and sometimes the only honest one. The trick is knowing which situation you're actually in.

Is it the code, the platform or the people?

Before you price anything, work out where the pain is coming from. The symptoms often look the same from the outside, but the causes are very different, and so are the fixes.

Technical debt costs businesses a lot. McKinsey found that CIOs estimate it at 20 to 40% of the value of their entire technology estate.

Their later research showed that paying it down can free engineers to spend up to 50% more of their time on work that moves the business forward. But not every slow, painful system is a debt problem. Here's how to read the signs.

• "Small changes take ages." Could be the code, could be the people. If the codebase has no tests and no documentation, any developer will move slowly. If it does have both and things are still slow, look at the team and the process first.
• "Every release breaks something else." Usually the code. Tangled dependencies and missing tests mean nobody can change one part safely. This is classic refactor territory.
• "Only 1 person understands it." A people and process problem dressed up as a tech problem. Fix the knowledge gap before you spend a penny on new code.
• "We simply can't do X on our platform." Usually the platform. If the thing you need (a trade checkout, multi-currency, a new integration) fights the platform's core design, no amount of tidying will fix it.
• "We can't find developers for this stack." The code. Ageing or niche frameworks get harder and pricier to support every year.
• "The last agency said it needed rebuilding too." Possibly the people. A team that struggles with an existing codebase can be quick to recommend replacing it.

When better people really are the fix

Sometimes the most honest answer is that the system is fine and the support around it isn't. The signs are easy to spot. Fixes take weeks because nobody reviews or tests them. There's no staging site, releases happen without a plan, and nobody can explain how the build fits together.

In that case, a new team with a proper process, a shared codebase and clear documentation can often turn things around quickly, with no rebuild needed. That's a far cheaper answer than starting again, so rule it out first.

When e-commerce brands should rebuild

For online retailers, the rebuild question is mostly a platform question. The store works, but the business has outgrown the shape of it. These are the triggers we see most:

• Several stores that have drifted apart. Regional sites that started as copies now have different content, different quirks and different running costs.
• A catalogue the platform can't model. Products sold by width, length and material, made to order, or with dozens of genuine variants that a standard setup can't handle cleanly.
• Retail and trade customers forced through the same journey. Trade buyers need net pricing, their own shipping rules and invoicing. Bolting that onto a retail checkout rarely ends well.
• A legacy platform with no upgrade path. If security updates have stopped or every plugin is a workaround, refactoring only delays the inevitable.
• Stock and orders living in separate systems. If your shop, your warehouse and your physical store don't agree, you're paying for that every day in manual work.

If 2 or more of these sound familiar, a replatform is worth serious consideration. If none do, your store probably needs a refactor, a design refresh or a better support setup instead.

When to rebuild an app or digital product

Knowing when to rebuild an app is harder, because apps carry more logic and more users depend on them working every day. Our default advice is to refactor first, in small, safe steps, and only rebuild when one of these is true:

• The framework is deprecated. If the tools it's built on no longer get updates, you're carrying a security risk and a hiring problem at the same time.
• The architecture can't support where the product is going. If the next stage of the roadmap (more users, real-time features, new markets) needs a structure the app was never designed for, patching won't get you there.
• Every new feature breaks 2 old ones. When the cost of change keeps climbing no matter who works on it, the technical debt sits in the foundations.
• Security or compliance gaps are baked in. Some problems sit so deep in how data is stored and handled that fixing them properly means rethinking the build.

Even then, a rebuild doesn't have to be all or nothing. Often the better route is to replace one part at a time while the existing product keeps running. Users get improvements sooner and you avoid a long freeze where nothing new ships.

How long does a rebuild take? Real timelines from our projects

Most articles on this topic give you theory. Here's what refactors and rebuilds have looked like across our recent work.

• A targeted refactor: a few weeks. For one client, prices, product titles and descriptions were hardcoded across their site, so every change needed a developer. We moved them into a managed system the team could update themselves. The work ran in phases over a few weeks, and the front end refactor itself took around 2 weeks of development. The rest of the site stayed exactly as it was.
• A marketing website rebuild: 6 to 9 weeks. For a brochure site on Webflow or WordPress, we typically plan 6 to 9 weeks from kickoff to launch. That covers discovery, design sign off, build, redirects and handover.
• A full e-commerce replatform: several months. A complex store with a large catalogue, trade customers and integrations is a much bigger job, and it's where timelines are most likely to stretch.

Here's the part people don't expect. When a rebuild runs long, it's rarely the code. It's the product data that needs cleaning and the content nobody has owned for years. It's decisions waiting on the right person, and extra scope that appears once people see what's possible. Plan for those and your timeline gets far more honest.

The Stripes Company: from 4 legacy sites to 1 Shopify store

The Stripes Company is a UK striped fabric specialist that sells to both consumers and trade customers. Years of organic growth had left them running 4 regional sites, each with its own quirks, costs and content drift. Their catalogue held 300 to 400 SKUs across fabric widths, lengths, trims and materials, with trade customers who needed a completely different way to buy.

This was a clear rebuild case. A refactor couldn't merge 4 sites, and the old platform couldn't model the catalogue properly. So we rebuilt on Shopify as one international store. That meant custom variant logic for made to measure fabric, a dedicated trade experience and live stock shared with their factory outlet. A careful SEO migration protected years of search traffic.

It took longer than first planned. The catalogue was rebuilt from the ground up rather than imported as it was, and new requirements emerged as the project went on. That's exactly the pattern above, and it was the right call. Sales went up more than 15% overnight when the new store launched, and the business now has a foundation it can grow on.

How to decide before you spend

Before you commit budget to either route, get clear answers to these 5 questions:

1. What exactly is slow, broken or impossible today? List real examples, not general frustration.
2. Is the cause the code, the platform or the people? Use the signs above to sort each example.
3. Can your current platform do what the next 2 to 3 years need? If the answer is no, a refactor only buys time.
4. What's the risk of change? Think revenue, search rankings, customer habits and team time.
5. Who will own it afterwards? A rebuild without a support plan slides back into the same problems.

The hard part is answering question 2 without bias. Your current team may defend the code. A new agency may want the bigger project. That's where the Foundation Audit comes in.

It's an independent review of your website or product. It covers UX, UI, brand, SEO, visibility in AI search, performance on mobile and desktop, accessibility, security, privacy signals, your tech stack and how you compare to competitors. It ends with a clear verdict: build on what you have, or rebuild. You also get a prioritised plan of what to fix now, next and later. The Foundation Audit is currently available on request.

Rebuild or refactor: make the call with evidence

Rebuild or refactor isn't really a technical choice. It's a business decision about where your problem actually sits.

Separate the code, the platform and the people before you spend anything. Refactor when the foundations are sound, and rebuild when the platform or architecture can't take you where you're going. Whichever route you pick, plan for data, content and decisions, because that's where timelines really slip.

If you're stuck between the 2, get an outside view before you commit. Get in touch to request a Foundation Audit and we'll tell you straight whether you need a rebuild or just a better way of working.

FAQs

Is it cheaper to refactor or rebuild?

A refactor is usually cheaper upfront because you keep what works and improve it in steps. But if the platform can't support where the business is going, refactoring can cost more over time as you keep paying for workarounds. Compare the cost of each route over 2 to 3 years, not just the first invoice.

How long does a website rebuild take?

For a marketing website rebuild, we typically plan 6 to 9 weeks from kickoff to launch. A complex e-commerce rebuild with a large catalogue and integrations takes several months. The biggest variables tend to be product data, content and how quickly decisions get made.

How do I know if my developers are the problem?

Look at process before code. If there's no testing, no staging site, no documentation and only 1 person understands the build, the issue may be how the work is run. An independent review can tell you whether the code itself is sound.

Will a rebuild hurt my SEO?

It can if it's done carelessly. Changed URLs, lost metadata and a slower site can all damage rankings. A proper migration with redirect mapping, carried over metadata and performance testing protects the traffic you've already earned.

Can you refactor and replatform at the same time?

Yes, and it's often the smart move. When you replatform, you rebuild the parts that need it and bring across what still works, such as content, structure and SEO equity. It's rarely a choice between keeping everything and throwing everything away.

When is moving to Shopify worth it?

Shopify makes sense when you're spending too much time and money keeping a custom or legacy platform running, or when you need things like international selling, unified stock and reliable checkout without building them yourself. If your current setup does the job and just needs tidying, a refactor may serve you better.