Keep building if the foundations hold, fix first if they hold but need work, rebuild only if the foundations themselves are the problem. That's the short answer. Most of the work is finding out which one you're looking at, because the people who built the thing are rarely the right people to tell you.
The question usually arrives the same way. Features are taking longer than they used to, every release breaks something, and a developer has said the words "it might be easier to start again". You can't judge that from the outside, and you shouldn't take it on trust from the inside either. A rewrite is the most expensive option on the table, and it's also the one that suits a developer who didn't write the original and would rather not inherit it.
Signs that point towards keeping it
The product works and customers use it. That sounds obvious, but a working system is carrying years of decisions about edge cases that nobody wrote down, and a rewrite throws all of it away.
New features take longer than they should but they do get done. Slow is a different problem from stuck.
The data model makes sense. If the way customers, orders, accounts and permissions are stored matches how your business actually works, you've got the hardest part right. Screens, endpoints and styling can all be replaced one piece at a time.
Signs that point towards rebuilding
The data model is wrong in a way that touches everything. Say the system assumes one user belongs to one company, and your business now sells to groups of companies. Every screen, every report and every permission check depends on that assumption.
Nobody can run it safely. If a change needs a developer to remember eleven manual steps, and releasing it is a coin flip, the cost of every future change includes that risk.
The technology is end of life, and not just unfashionable. A framework that no longer receives security fixes is a real problem. One that's a few versions behind is a maintenance task.
Why rewrites so often fail
A rewrite looks cheap on paper because the old system gives you a specification. You already know what it needs to do.
What you don't see is that the old system does a hundred things nobody remembers asking for. The invoice rounding rule from 2021, the customer who needs a special export, the workaround for a payment provider quirk. Each one is invisible until it's missing.
While the rewrite runs, the business doesn't stop. You end up maintaining two systems, and the new one is always chasing the old one. Deadlines slip, because the last stretch of a replacement is where all those forgotten behaviours live.
Rebuilding is sometimes right. It's right less often than the people proposing it suggest, and it's almost never right as a whole-system, all-at-once switch.
What a review can and can't tell you
An independent review looks at the code, the structure, the way it's deployed and the way it's tested, and gives you a view you can act on. It can tell you whether the foundations are sound, where the risk sits, what's fixable and roughly how much work each fix is.
It can't tell you whether the product is a good idea, or promise that a fix will go smoothly. It also can't see anything it wasn't given access to. If a system depends on a hosting account or a third-party service nobody can get into, that gap is itself part of the finding.
What the three answers mean in practice
I write these reviews so the answer is one of three, stated plainly at the top.
Continue means the codebase is in good enough shape to build on. There will still be findings, but none of them change the plan.
Fix first means it's worth keeping, and there's a short list of things that should be dealt with before you build anything new on top. Typically that's security gaps or a deployment process that only one person understands, and sometimes missing tests around the parts that handle money. You get the list in priority order.
Rebuild means the foundations can't carry what you need, and patching them will cost more than replacing them. Even then, the report should say what to keep: the data, the design decisions, the parts that work. A rebuild that starts from the old system's lessons is a different project from one that starts from nothing.
Whichever it is, you get it in writing, with the evidence behind it, so you can put it in front of your board or your supplier.
If you're weighing this up now, the code and architecture review is what I'd suggest, and it's a fixed fee. If you'd rather talk it through first, get in touch and tell me what you've been told so far.