Rebuild a web app when the constraints of the existing system make the required business outcome harder or riskier to achieve than a replacement. Repair it when the important problems can be isolated and corrected at a reasonable total cost. Many systems need a third option: gradual replacement while the business keeps running.
That sounds straightforward until the current app is unreliable, the team is frustrated and a new developer says it would be easier to start again. At that point, a rebuild can feel like relief. Relief is not a business case.
The decision should compare future work, operational disruption and the risk of carrying existing responsibilities into a new system. Money already spent explains how you arrived here. It cannot decide which option is better from today.
Describe the business problem before the code problem
“We need a modern stack” does not explain what the business needs to accomplish. Perhaps customers cannot complete onboarding, new features take too long, or the system cannot support the required permissions. Those are specific problems against which alternatives can be judged.
Separate symptoms from causes. A slow report might come from an inefficient query, an unsuitable data model or a third-party service. Only one of those explanations may require substantial architectural change. The slow screen alone cannot tell you which one is true.
Write a small set of outcomes with constraints. Include the workflows that must continue, the deadline, data that must survive, required integrations and any unavailable downtime. These constraints often matter more than the framework being proposed.
Establish what is actually wrong
A useful review follows important workflows from the interface through the application and data. It examines where rules are enforced, which components depend on each other and where failures occur. It should also inspect deployment, monitoring and recovery.
The result should distinguish confirmed defects, suspected structural limits and ordinary maintenance work. “The code is messy” is not enough. Show which changes are expensive or unsafe because of that structure, and what correction would alter the situation.
A reviewer does not need to read every line to find every possible issue before providing useful direction. They do need to describe the sample, the limits of the review and why the observed problems support their recommendation.
When repair is the better investment
Repair is attractive when the app already performs valuable work, its important responsibilities are understood and the faults have identifiable boundaries. An unreliable integration, missing test coverage or one poorly designed module may be fixable without replacing the whole product.
Existing behaviour also has value. Staff have learned the system. Customers know how it works. Years of small rules may reflect real requirements that nobody has written down. A repair preserves that knowledge while improving the parts that cause trouble.
The counterargument is that repeated local repairs can become avoidance. If each change requires touching unrelated components and creates further faults, ask whether a structural correction is overdue. Repair should improve the system's trajectory, not merely postpone the next incident.
When replacement deserves serious consideration
Replacement becomes more credible when the required operating model conflicts with the foundations of the current app. For example, a product originally designed around one company may need genuine separation between many organizations, while its data and permission assumptions are spread throughout the system.
Even then, the choice is not automatic. A careful refactor may be possible. Compare the actual paths: changing the existing design, replacing the affected area and building a new system. Each path needs a realistic scope rather than an optimistic description.
Another reason to replace may be an unmaintainable dependency or platform constraint that blocks an essential requirement. Verify the constraint and available alternatives. A technology being unfashionable is different from it preventing the business from operating safely.
Consider gradual modernization
A gradual approach replaces one responsibility at a time. The old system continues handling the rest until the replacement has demonstrated that it works. This can reduce the amount of business behaviour moved in a single release.
An illustrative starting point might be replacing reporting while leaving order processing intact. That works only if ownership of the data is clear and the reporting change does not quietly introduce competing versions of business rules.
Gradual work has a cost too. Teams may temporarily support two systems, synchronize information and maintain interfaces between them. Use it when those transitional costs are justified by continuity or reduced migration risk, not because it sounds less frightening than a rebuild.
Compare complete costs
The replacement estimate must include discovery, migration, testing, deployment, training and a period of support. It also needs to account for work that changes while the new product is being built. The business does not usually stop learning during development.
The repair estimate should include the changes needed to make future work dependable, not just the visible bug. If the underlying problem is missing tests or unreliable releases, restoring one screen without addressing those conditions may produce a misleadingly low quote.
Compare both options over a period that matches the decision. A short-lived internal tool and a core product expected to evolve for years should not be assessed with the same horizon. Avoid false precision when future requirements are still uncertain.
Migration is part of the product
A new interface is not a completed replacement if users, records, files and permissions have not moved correctly. Decide how records map, how errors will be identified and what happens if the cutover needs to be reversed.
Rehearse with representative data. Reconcile record counts and important totals, but also check meaning: a migrated booking linked to the wrong customer is not correct simply because the number of bookings matches.
Set a clear decision point for switching traffic or users. Name who can authorize it and what evidence they need. The migration plan should exist before the replacement is almost finished.
Ask for a recommendation you can challenge
Request a short comparison of repair, partial replacement and full rebuild. For each option, ask for the scope, main assumptions, unresolved questions, business disruption and major risks. Ask what evidence would change the recommendation.
A useful first phase can reduce uncertainty without committing you to a full build. The deliverable might be a verified diagnosis, a migration experiment or a bounded correction that demonstrates whether the structure can support further work.
The right decision is the one that gets the business to a maintainable result with acceptable disruption. Sometimes that is a rebuild. Often it is a more precise intervention than the initial conversation suggested.
Frequently asked questions
Is old code automatically worth replacing?
No. Age can introduce maintenance constraints, but useful, understood and supportable software may still be a sound foundation.
Should the same agency review and rebuild the app?
It can, but ask for a diagnosis and options before accepting the build recommendation. An independent second opinion can help when the commitment is substantial.
Can we change frameworks without rewriting everything?
Sometimes. It depends on how responsibilities are separated and how the interface connects to the rest of the application. Treat it as an architectural question.
How do we avoid rebuilding the same problems?
Document the important business rules, test the replacement against them and include operations, ownership and migration in the brief.
What if we cannot afford the ideal solution?
Identify the highest-consequence risks, reduce scope and plan a staged improvement. A constrained plan should state its limits rather than pretend to solve everything.