When to rebuild from scratch vs refactor an existing digital product

Every team eventually has the conversation. Technical debt is accumulating, new features are taking three times longer than they should, and someone finally says it out loud: "Can we just rebuild this?"

That frustration is valid. But rebuilding is expensive, risky, and always takes longer than anyone estimates. And refactoring in the wrong place is money spent propping up a system that is past saving.

At Livewall, we design and build digital products for brands like KLM, AvroTros, and Decathlon. We have been on both sides of this decision more times than we can count. What we have learned: the choice is never really about technology preference. It comes down to a handful of honest questions about the business.

Start with the business question, not the technical complaint

Most rebuild conversations start with technology: an outdated framework, a codebase nobody wants to touch, an architecture that has long since stopped making sense. But technical frustration is rarely the real problem.

The question that actually matters: can this system deliver what the business needs over the next two to three years?

If the answer is yes, even if there are obstacles, refactoring is almost always the smarter choice. If the answer is no, that is your real case for rebuilding.

What we see in practice: teams decide to rebuild based on technical irritations, while the underlying business logic and user flows are fundamentally sound. The result is a brand new system that reproduces exactly the same problems, but now without any track record or institutional knowledge baked in.

The five questions that drive the decision

1. Does the architecture block new functionality?

There is a difference between slow development and blocked development. If features structurally cannot be built due to fundamental architectural constraints, that is a signal to rebuild. If features are just slow, that is almost always solvable through targeted refactoring.

2. Are there critical security or scalability risks?

Some systems run on infrastructure that cannot be safely updated without rearchitecting the whole thing. If you have a platform that collapses under peak traffic or carries fundamental security issues that cannot be patched locally, rebuilding is defensible.

3. Does the team still understand the system?

Knowledge that lives only in people's heads is dangerous, but it can be documented and transferred. If nobody on the current team understands how the system works and documentation is absent, maintenance costs grow exponentially. That is a serious indicator.

4. How much critical business logic would a rebuild put at risk?

Years of edge cases, user-driven fixes, and business rules are often buried silently inside an existing system. When you rebuild, you lose all of that. We see this regularly: a new system that introduces problems after launch that the old system had long since quietly solved.

5. What is the time horizon and business pressure?

Rebuilds take longer than teams estimate, every time. If there is business pressure to deliver within six months, a full rebuild is almost never achievable without compromising quality. Targeted refactoring is the more realistic option.

When refactoring is the right call

Refactoring works well when a product is functionally sound but technically ageing. Concrete signals:

• Core functionality works as users expect
• Problems are localisable and repeatable
• The team can identify which modules are causing the most pain
• The business logic is valuable and well understood

In these situations, a modular refactoring approach is effective: work from the outside in, start with the most painful components, and validate continuously with users. This is also how Livewall approaches web application development: iteratively, risk-driven, and with genuine respect for what the existing system already does well.

The Sportvisunie community platform is a good example. The platform has been improved and extended multiple times over its lifetime without a full rebuild. The core community functionality stayed intact while the technical stack was modernised progressively.

When rebuilding is genuinely justified

There are situations where rebuilding is the only honest answer. Examples:

Fundamental architecture mismatch. Some systems are structured in a way that the core architecture literally prevents the product from becoming what it needs to be. A monolithic system that needs to become multi-tenant, or a legacy system that requires deep API integrations the current setup simply cannot support.

Technology that has fallen out of active support. If the underlying technology no longer has an active community or vendor support, refactoring means building on sand.

The product's purpose has fundamentally changed. Sometimes a new product is simply the honest answer. Not because the existing system is bad, but because the business requirements have shifted so substantially that a continued match is not realistic.

The AvroTros Eurovision app illustrates this well. The scale requirements, live environment, and usage intensity all pointed toward a deliberate architectural decision from scratch, rather than trying to stretch an existing platform into something it was never designed for. Working with a digital product agency that can assess these constraints early prevents expensive course corrections later.

The trap of the hybrid trajectory

A pattern we see regularly: teams decide to rebuild but try to keep the existing system running in parallel. That feels safe. It almost never is. Two systems to maintain, two sets of bugs to fix, two onboarding paths for new team members.

If you decide to rebuild, be clear about the migration date and work toward it. Uncertainty around the transition leads to halfhearted choices in both directions.

A solid digital strategy helps structure that decision: what moves when, which data needs to be migrated, and what is the contingency if the timeline slips. That gives teams the clarity to make the right decision rather than the safe one.

At Livewall, this is part of the work we do before a single line of code is written. Whether it is a refactor or a rebuild, the starting point is always a clear-eyed view of where the existing product stands and what the business genuinely needs next.