When to Rebuild vs. When to Patch (A Framework)

Every developer has felt it: the urge to burn everything down and start fresh. "If we just rebuilt this properly..."

Sometimes that's right. Usually, it's not. Here's the framework we use:

Patch when:

The core architecture still makes sense. It's just accumulated cruft. A good refactor beats a rewrite.

You can ship improvements incrementally. Small wins build momentum and reduce risk.

The problem is localized. If only one module is causing issues, replace that module—not the whole system.

Your team knows the codebase. Institutional knowledge is worth more than people admit.

Rebuild when:

The technology is genuinely dead. If your framework has no security updates and no community, that's a real risk.

The architecture fundamentally can't handle your new requirements. You can't patch a monolith into microservices.

Every change takes 10x longer than it should. There's a point where accumulated technical debt costs more than starting over.

You're already doing a rebuild in disguise. Sometimes teams patch so extensively that they're rewriting anyway, just without a plan.

The uncomfortable middle:

Most situations aren't clear. You could rebuild or patch. Both would eventually work.

In those cases, I ask: "What does the team want to do?"

Engineers who believe in what they're building do better work. If your team is demoralized by the existing codebase and energized by a rebuild, that matters. But if they just want new tech for resume purposes? That's different.

The rule we follow: bias toward patching, but don't be religious about it. The goal is shipping value, not preserving code or chasing novelty.