Rewrite or refactor: the question is what you can still change

The two get used loosely, which is how teams end up arguing past each other. They're precise terms. Refactoring means changing the internal structure of code without changing what it does — you keep the behaviour and improve the shape, in small, reversible steps, with tests catching you if you break something. It's maintenance, done continuously or in a focused push.

A rewrite is the opposite bet: you set the existing implementation aside and build it again, often on a new stack. The product's behaviour is the target, but the code is new. Refactoring is renovating the house room by room while you live in it; rewriting is building a new house and moving. The right choice isn't a matter of taste — it depends almost entirely on what you're still able to change in what you have.

Refactoring is the right, cheaper, lower-risk answer far more often than founders expect. If the app is built in code you own, the architecture is fundamentally sound, and the pain is localised — a slow module, a tangled corner, an area that's become scary to touch — then you improve it in place, behind tests, without betting the company on a big-bang cutover.

The tell is that you can still ship. If features are still going out, and the problem is that they're going out slower or more nervously than they used to, that's a refactoring problem. You're not trapped; you're carrying debt, and debt is paid down incrementally. Reaching for a rewrite here trades a manageable, known situation for a risky, unknown one — the exact mistake the classic warning is about.

If a rewrite is forced, the way to avoid Netscape's fate is to refuse the big bang. The safe pattern is incremental: keep the old system running and serving users, build the new one alongside it, and move functionality across a piece at a time — the "strangler fig" approach, where the new system gradually surrounds and replaces the old one until the original can be switched off.

For a no-code app that means the old platform keeps paying its way while you rebuild the highest-risk or highest-cost part first, migrate the data with reconciliation against the source, and cut over feature by feature with a rollback path at every step. A rewrite fails when it's a two-year rebuild in the dark that has to be perfect on launch day. It succeeds when it's a sequence of small, reversible migrations, each one live and earning before the next begins.