When to Refactor and When to Rewrite: An Architectural Perspective

If you don’t have a Medium subscription, you can still read by **clicking this link.**

At some point in every product's life, the question comes up—often urgently, sometimes quietly: “Should we refactor our system… or just rebuild it from scratch?”

It’s rarely an easy call.

Refactoring sounds safer, but it can drag on endlessly without meaningful impact. Rewriting feels liberating, but it’s a high-stakes gamble with time, scope, and trust.

I’ve seen both approaches succeed and fail. In one case, a slow, methodical refactor breathed new life into a legacy product. In another, a rewrite took nine months, burned out the team, and ended with a half-finished app that no one wanted to maintain.

There’s no one-size-fits-all answer—but there is a way to decide with confidence.

This article breaks down the key considerations I use when helping engineers make the right choice for their context. Whether you're trying to evolve a stable product or escape a broken foundation, the first step is understanding which path you're actually on.

Refactor

When you’re still standing on solid ground

Refactoring is about reshaping and improving the codebase without changing its external behavior. It’s often the right call if the structure is wrong, but the foundation still holds.

Choose to refactor when

• The system still delivers consistent value: If users rely on it and the business continues to grow, you likely don’t need to throw it away.
• Core business assumptions haven’t changed: If the product still solves the same problem for the same audience, you don’t need a new system, just a healthier version of the one you have.
• You can isolate the pain: Is it just authentication that’s messy? Just the billing pipeline? Just one bloated service? If the problems are localized, so should the solution be.

The team can still ship while improving — This is key. If developers can deliver features and chip away at tech debt, you're in a good spot.

Refactoring is surgical

It requires:

• Discipline
• Strong test coverage
• Well-defined interfaces

But it lets you evolve, not burn down.

What refactoring gives you

• Faster, safer iteration
• Reduced risk
• Improved team confidence
• Continuous delivery momentum

It’s often less glamorous, but it keeps the business running, and improves developer experience along the way.

Rewrite

When the Foundation Itself is Broken

Sometimes the structure isn’t just bad—it’s fundamentally misaligned with what your business is today. That’s when a rewrite may be the lesser evil.

Consider rewriting when

• The architecture no longer reflects the business: Maybe you started as a monolith, but now you're offering a platform. Or you pivoted from B2C to enterprise. The system may be holding back your evolution.
• Everything is brittle or painfully slow When onboarding takes weeks, CI/CD breaks daily, and small changes risk taking down prod—it’s often a symptom of deep systemic issues.
• The team is already rewriting informally This is one of the most common anti-patterns: shadow rewrites. Developers spin up new services, avoid the old ones, and logic gets duplicated. No one owns the whole picture anymore.
• You’ve pivoted hard If your product has changed direction significantly, and your old assumptions are baked into every layer of the system, it might be time to reset.

Rewrites are risky

They cost time, focus, and carry the danger of

• Scope creep
• Missed delivery deadlines
• Feature regression
• Team burnout

But continuing to build on a broken system can be worse. You might still fail—but slowly, and expensively.

The Worst Case: Shadow Rewrites & Frankenstein Systems

Half-rewriting in the background is the most dangerous outcome. It results in:

• Two systems with duplicate logic
• No clear ownership or vision
• A team that trusts neither codebase

This is often a result of indecision at the leadership level. When engineers are frustrated, but management won't approve a rewrite—or vice versa—the system silently fractures.

The cost isn’t just technical—it’s organizational. You fragment your architecture, your team, and your product strategy.

Two Questions to Anchor the Decision

When I work with teams facing this dilemma, we always start here:

1. Are you trying to improve the system—or escape it?

Are the problems fixable with effort and care? Or are they symptoms of a deeper misalignment? This question helps clarify intent and sets expectations.

2. Can you ship value while making progress?

If your team spends every sprint duct-taping and firefighting, you’re not innovating—you’re surviving. You either need to change how you work—or the system you work in.

The Bottom Line

You don’t rewrite a system because it’s ugly. You rewrite because the system can no longer carry the next 12 months of bets your company is making.

And you don’t refactor just to feel clean. You refactor because you can—and it’s the fastest way to go further without stopping the train.

Every engineering leader eventually faces this fork in the road. Make the call with clarity, not just frustration. And once you decide, commit.

Your team, your customers, and your business will thank you.

That’s all for today, happy coding, everyone! 😊