Every engineering team hits this moment eventually. The codebase is slowing you down. Features that should take a week take a month. You dread touching certain files. And someone — usually a developer, sometimes a founder — says: "We should just rewrite this thing from scratch."

Maybe. Or maybe not.

This is one of the most consequential decisions you'll make on a software product. Get it wrong and you're looking at months of lost progress, regressions, or a new codebase with all the same problems. Get it right and you buy yourself years of clean, fast, maintainable development.

Here's how to think through it.

What is Refactoring?

Refactoring is changing the internal structure of your code without changing what it does for users. Same functionality, cleaner implementation.

You refactor to:

• Fix a tangled section of code that's become impossible to reason about
• Improve performance in a specific area
• Reduce duplication across the codebase
• Make a section easier to test
• Prepare code for a new feature without breaking what already works

The key thing about refactoring: users don't notice. The product keeps working. You're tidying up behind the scenes.

When to Refactor

Refactor when the codebase is fundamentally sound but has specific problem areas. Signs you should refactor rather than rewrite:

• You can identify which parts are causing problems (not "everything is bad")
• New features are still shippable, just slower than they should be
• The core architecture makes sense — it's the implementation that's messy
• Your team understands the existing code well enough to improve it safely
• The tech stack is still viable (not deprecated, not unsupported)

Real example: We worked on a software platform for divorce filings in Queensland. The dashboard needed a significant update — real-time notifications, a new case management view, better status tracking. The underlying data model was solid. We refactored the dashboard layer without touching the core filing logic. It shipped cleanly. No regression. No drama.

What is Rewriting?

A rewrite means starting over. New codebase, likely new architecture, sometimes a new tech stack. You keep the product knowledge and requirements — but the code itself gets thrown away.

This sounds appealing when you're frustrated with existing code. It rarely is.

Joel Spolsky called it "the single worst strategic mistake that any software company can make." He wasn't wrong. Rewrites almost always take longer than anyone estimates, often by a factor of 2–3x. And without discipline, you end up replicating the same problems in a new codebase.

That said — sometimes it's genuinely the right call.

When to Rewrite

Rewrite when the existing codebase is structurally beyond saving. Signs you're actually there:

• The core architecture is wrong in a way that can't be fixed incrementally
• You're on deprecated technology with no upgrade path (end-of-life frameworks, unsupported languages)
• The technical debt is so deeply embedded that every change breaks something else
• Nobody on the team understands how the system actually works
• The cost of maintaining the old system exceeds the cost of rebuilding it

Real example: We worked with a real estate client on a Pre-Settlement Inspection management system. They wanted what sounded like a simple UI update. We started pulling at threads and found deeply outdated backend logic — the kind where every fix creates two new problems. After a proper assessment, we recommended a full rewrite. It was the right call. The new system is maintainable, extensible, and the team can actually move fast on it.

The Decision Framework

Before committing to either, do this first: actually audit the codebase.

Not a vibe check. Not a developer's gut feeling. A proper assessment of:

• What specifically is causing pain? (Feature velocity? Bug rate? Performance? Fragility?)
• Can those specific things be improved without touching everything else?
• What's the real risk of each approach? (What breaks if refactoring goes wrong? What's the actual timeline for a rewrite?)
• Do you have the people and process to execute a rewrite properly?

A lot of "we need a rewrite" conversations end with "actually we need to refactor these 3 modules and sort out our deployment pipeline." That's a much cheaper and faster path.

The Middle Option Nobody Talks About

There's a third path worth knowing about: incremental rewriting.

Rather than a big-bang rewrite, you replace one module at a time while keeping the rest of the system running. The strangler fig pattern. It's slower than a full rewrite in isolation, but it keeps the product live and derisk the process significantly.

For larger systems, this is often the right answer — especially when you can't afford to have the product offline or in development limbo for six months.

The Bottom Line

• Refactor when you have specific problems in an otherwise functional codebase
• Rewrite when the architecture is fundamentally broken and there's no viable upgrade path
• Incremental rewrite when you need to modernise a large system without stopping the world

And if someone on your team says "we should rewrite everything" — ask them to specify exactly what's broken and why it can't be fixed in place. That conversation usually clarifies things quickly.

If you're unsure which camp you're in, get in touch. We do codebase assessments and can give you an honest read.