7 signs your app needs a rebuild (and 3 it doesn't)

You need a rebuild when the cost of change has outrun the cost of replacement — when every small feature takes weeks, breaks something else, and only one person understands why. You need a refactor (not a rebuild) when the bones are sound and the pain is localized. Knowing the difference is worth more than any single fix.

7 signs it's time to rebuild

• Every change is expensive. A "small" feature takes weeks because everything is entangled. The honest test: ask your team to estimate adding a simple settings toggle. If the answer involves the words "well, first we'd have to…," the architecture is billing you interest.
• The bus factor is one. Exactly one developer understands the system, and they're nervous. This isn't a people problem — it's a codebase that resists being understood, and it gets worse with every undocumented workaround.
• You can't hire for the stack. It's built on something niche, abandoned, or so customized no one else can read it. Every month you stay, the pool of people who can save you shrinks.
• Releases are scary. Deploys are manual, rare, and followed by a hotfix. Teams in this state start batching releases to avoid the fear, which makes each release bigger and scarier — a ratchet that only turns one way.
• It's slow or crashes — and no one can say why. No monitoring, no logs, no reproducible cause. You can't fix what you can't observe, and adding observability to a hostile codebase is often where rebuild math starts winning.
• Mobile, web, and backend disagree. The same action gives different results on different surfaces because there's no single source of truth. This one almost always traces back to a multi-vendor history — three teams, three interpretations of the spec.
• Security and compliance are "we'll get to it." Unverified payments, secrets in the code, no audit trail. These aren't features you're missing; they're liabilities you're accruing, and retrofitting them is routinely harder than rebuilding around them.

3 signs you should NOT rebuild (refactor instead)

• The problem is one module, not the whole system. A slow search screen or a flaky sync engine can be excised and replaced without touching the other 90% that works.
• The architecture is sound; the symptoms are performance or UX, which are fixable in place. A product that's ugly but observable, testable, and deployable is a renovation, not a teardown.
• You're rebuilding out of frustration, not evidence — "the last team annoyed me" isn't a technical reason. New teams systematically underestimate old code; some of what looks insane is load-bearing context nobody wrote down.

The hidden cost people forget — in both directions

Rebuild advocates forget that a rebuild freezes your roadmap: while the new system catches up to the old one's feature set, your users get nothing. Refactor advocates forget that "incremental improvement" on a terminal codebase is a treadmill — eighteen months of cleanup sprints that never quite reach the part where features get cheaper. The way out of the false choice is usually a strangler rebuild: keep the old system serving users while the new one replaces it surface by surface, highest-pain first. It costs more in coordination and less in everything else.

What a rebuild should actually start with

Not code — an audit. A good partner reads the codebase, maps what's salvageable, and gives you a "rebuild vs refactor" recommendation before anyone quotes a line of work. The audit should name what gets carried over (the data model usually survives; the schema is often the most valuable artifact in a legacy system), what gets strangled gradually, and what gets cut entirely. Rebuilding the wrong things is how you spend twice and ship late.

And insist the audit ends in a document you own. Even if you never hire that partner, a written map of your system's failure modes is worth the cost of the engagement — and it keeps the next vendor honest.