When to Rewrite Your SaaS Instead of Refactoring: A Founder’s Honest Guide

Most founders who want a rewrite don’t actually need one. And most who keep patching a broken codebase wish they’d cut earlier. The decision sits right at the intersection of technical reality and business pressure, which means it rarely gets made clearly – it gets made emotionally, usually after the fourth consecutive sprint where almost nothing shipped.

We’ve seen both failure modes up close. A rewrite that consumed eight months and didn’t move a single revenue metric. A refactor plan that kept getting extended until the original problem had compounded into something genuinely unfixable. Neither is inevitable, but both are common. What separates them is whether you’re diagnosing the actual constraint or just reacting to the pain of the moment.

The Signals That Actually Mean Rewrite

Not all technical debt screams rewrite. Some of it is just annoying. The signals that genuinely point toward starting over are more specific than “the codebase is messy” or “the team is frustrated.”

• The architecture is fighting the product direction. If your data model was built for single-tenancy and you’re selling to enterprise, or your core abstraction assumes one pricing model and you’ve since changed it twice, no amount of refactoring fixes the mismatch. You’re not cleaning a room – you’re trying to move walls without touching the foundation.
• New engineers can’t get productive in under two weeks. Onboarding time is a surprisingly honest proxy for codebase health. When a competent mid-level developer needs three weeks just to understand the flow well enough to make a safe change, the complexity has crossed into structural.
• The defect rate is accelerating, not stabilising. Refactoring normally bends the defect curve down over time. If you’ve been “cleaning things up” for six months and bugs are still multiplying, the interdependencies have been disturbed without being resolved.
• You’re on a framework or runtime that’s genuinely end-of-life. Not just old – actually abandoned, with no clear migration path. This one is rare, but when it applies, it’s unambiguous.
• The original builder is the only person who understands it. When knowledge can’t be transferred and the code doesn’t explain itself, you’re not maintaining software – you’re managing a dependency on a person.

One or two of these in isolation probably doesn’t justify a rewrite. Three or more at the same time, affecting the same part of the system, and the calculus changes fast.

What a Rewrite Actually Costs (and Why It’s Always More)

Here’s the figure founders usually underestimate: a full SaaS rewrite typically runs 1.5x to 3x the original build cost, and takes longer than the original build did. That’s not a knock on the engineers doing it – it’s structural. You’re building a known product, which sounds easier, but you’re also maintaining the existing system in parallel, migrating data live, managing customer expectations through a period of reduced velocity, and discovering that half the “quirks” in the original code were actually load-bearing decisions that weren’t documented anywhere.

A professional services SaaS we rebuilt last year – original build had been done quickly, on a tight budget, and had served the founder reasonably well for two years – ended up taking four months for a codebase that looked, on the surface, like a six-week job. The hidden cost was the business logic scattered across the database in stored procedures, a permissions model that had been extended ad hoc seven different ways, and an email notification system that had accreted fifteen conditional branches over two years of customer requests. None of that was visible in the initial scoping conversation. It never is.

Budget ranges in AUD for a rewrite, from our experience: a focused single-module rewrite (one core service, clean interfaces) might run $30K-$60K. A full application rewrite with data migration, parallel running, and production cutover is realistically $80K-$200K+ depending on complexity. Anyone quoting you less without a detailed discovery is either guessing or underscoping.

The Refactor Path: Where It Actually Works

Refactoring gets a bad reputation because it’s usually done wrong – either too incrementally (so it never meaningfully improves the system) or too ambitiously (so it balloons into an unofficial rewrite without the planning a rewrite deserves).

Targeted refactoring genuinely works when the architecture is fundamentally sound and the problem is localised. If your authentication module is a mess but the rest of the system is clean, refactor the auth module. If your API response times are slow because of N+1 queries in three specific endpoints, fix those endpoints. The mistake we see most often is treating localised problems as evidence of systemic failure and proposing a full rewrite when a focused, well-scoped refactor would close 80% of the gap.

The rule we use internally: if you can describe the refactor as a series of changes that each leave the system in a working state, it’s probably a refactor. If the path to improvement requires a period where the system is in an intermediate, broken state that you can’t ship – that’s a rewrite, whether or not you’re calling it one.

The Strangler Fig: When You Don’t Have to Choose

The strangler fig pattern gets mentioned in technical writing constantly, but rarely explained in terms of how it actually works in practice on a small team.

The idea is straightforward: you don’t rewrite the old system and then cut over. You build the new system piece by piece, routing traffic to it as each piece is ready, until the old system has been completely replaced. Like a strangler fig vine growing around a tree – eventually the vine is the structure and the original tree is gone.

This works particularly well for SaaS products where you have distinct functional modules – say, a reporting layer that could be rebuilt as a standalone service while the core application keeps running. You ship the new module, redirect that functionality, and the old code for that module becomes dead weight you can remove. Over six to twelve months, you’ve effectively rewritten the product without a big-bang cutover.

The trade-off is coordination overhead. For two weeks, you’re running two codebases. Someone has to make sure the data contracts between old and new stay consistent. Feature development in the strangled areas is frozen or slower during the transition. It’s not free – but it’s often the most financially sensible path for a product with a live customer base that can’t tolerate downtime or a frozen feature roadmap for six months.

How to Make the Call Without a Full Technical Audit

You don’t always have weeks and budget for a detailed audit before you need to make a direction decision. Here’s the quick diagnostic we run when a founder comes to us unsure which path they’re on.

1. How long does it take to ship a small feature end-to-end? Under a week is healthy. Two to three weeks is a warning. Four-plus weeks for something genuinely small means the system is fighting you.
2. Where do bugs cluster? Random distribution across the codebase usually means general quality issues – addressable through refactoring. If 70% of bugs come from the same two or three modules, those modules are candidates for targeted rewrite regardless of what the rest of the system looks like.
3. What’s the test coverage on the core business logic? Not the overall percentage – specifically the parts that process money, handle permissions, or touch customer data. Low coverage there means any change is high-risk, which inflates the cost of both refactoring and rewriting.
4. Ask the team, not the founder. Founders rationalise. Engineers working in the code every day usually have a clear and honest read on whether it’s salvageable. The answer “it’s bad but it makes sense once you know it” is meaningfully different from “nobody knows why half this works.”

The answers to those four questions will usually point clearly enough to make a confident recommendation without a month-long audit. If they don’t – if the answers are genuinely mixed – that’s almost always a case for the strangler fig approach rather than a binary choice.

The Conversation Worth Having Before You Spend

The rewrite-versus-refactor decision is one of the few where getting an outside read early is almost always worth it. Not because an agency will tell you what you want to hear – a good one won’t – but because the people who’ve been living in the codebase are often too close to it to see the pattern clearly. The team that built it is defending decisions they made under constraints that no longer exist. The team that inherited it is frustrated in ways that may or may not be pointing at the real problem.

We’ve talked founders out of rewrites they didn’t need. We’ve also told founders that the patch they were planning to commission was going to cost more over two years than the rewrite they were trying to avoid. Neither conversation is comfortable, but both are better than the alternative.

If you’re sitting on this decision right now – and it’s genuinely one of the most expensive calls you’ll make in a product’s life – talk to Amora about your build before you commit either direction. An hour of honest diagnosis is worth a lot more than a month of moving in the wrong one.