Not Sure Which Path Fits Your Product?
Every SaaS product eventually reaches a point where new features get harder to ship and the codebase stops feeling like an asset. The question at that point isn’t whether to act — it’s which of three genuinely different paths to take, because picking the wrong one is expensive in a way that’s hard to reverse.
Patch: buy time without solving the underlying problem
Patching means continuing to build on the existing foundation — targeted fixes, incremental refactors, shoring up the worst hotspots. It’s the right call when the core architecture is still sound and the pain is localized to specific modules, or when the business genuinely can’t absorb the risk of a larger effort right now. The trap is using patching as a permanent strategy for a foundation that’s actually failing; at that point every patch gets more expensive than the last, and the team knows it before leadership does.
Replatform: keep the logic, change the foundation
Replatforming means moving the same business logic onto a different technical foundation — a new database, a new hosting model, a modernized framework version — without rewriting the product from scratch. This fits when the product’s logic and user experience are still competitive, but the technical foundation has become a genuine constraint: it can’t scale, it’s on infrastructure that’s being deprecated, or it’s become too expensive to run. Replatforming is usually faster and lower-risk than a full rebuild, because the hard-won business logic — the part that actually took years to get right — survives the move.
Rebuild: when the product itself, not just the code, needs to change
A full rebuild makes sense when the market or the product requirements have moved past what the current architecture can reasonably support — not just technical debt, but a genuine mismatch between what the product needs to do now and what it was designed to do originally. This is the most expensive and highest-risk path, and it’s also the one most often chosen for the wrong reason: because rewriting feels more satisfying to an engineering team than untangling what exists. A rebuild should be justified by product and business requirements, not by a preference for clean code.
The decision test that actually works
A useful way to separate these three: if you fixed the three worst parts of the current system, would the product be competitive again? If yes, patch. If the logic is fine but the foundation can’t carry it, replatform. If the answer is “even with those fixes, the product couldn’t do what the market now needs,” that’s the case for a rebuild — and even then, an incremental, module-by-module rebuild that keeps the old system running in parallel is almost always lower-risk than a big-bang replacement.
The costliest mistake isn’t picking patch, replatform, or rebuild — it’s picking based on internal preference rather than an honest read of where the actual constraint sits: the code, the foundation, or the product itself.