The Rewrite That Killed the Company
Rage-quitting your own codebase hands your market position to competitors who kept shipping.
The hook
I watched a fintech company die in 2022. Not from bad product-market fit. Not from a funding drought. From a rewrite. They had a working Django monolith serving 60,000 daily active users, revenue growing 15% quarter over quarter, and an engineering team that could not stand looking at the code anymore. So they stopped shipping features and started rewriting in Go. Fourteen months later, they had a beautiful new codebase and 40% fewer customers.
आपुले हित आपण पाही · Look After Your Own Interests
आपुले हित आपण पाही । संकोच तो न धरी कांही ॥
शेजारणीच्या गेली रागे । कुत्र्यांनी घर भरले मागे ॥
तुका म्हणे वायांच्या रागे । फेडिले सावले देखिले जगे ॥
A woman stormed out in anger at her neighbor; while she was gone, dogs overran her house. Anger at others causes you to abandon your own position, and the damage happens at home, not where you aimed.
What I keep seeing
I have sat in the meeting where the rewrite gets proposed. You have too. The room is full of engineers who are genuinely frustrated. The Rails monolith has 800,000 lines, three ORM patterns coexisting, a test suite that takes 47 minutes, and a deployment pipeline held together with bash scripts nobody wants to touch. Someone pulls up a dependency graph that looks like spaghetti rendered in GraphViz. The tech lead says, "We cannot keep building on this." The room nods.
The frustration is always legitimate. I have never seen a rewrite proposed out of laziness. The codebase really is bad. But here is the part nobody says out loud: the rewrite is not a technical decision. It is an emotional one dressed in architecture diagrams.
The mechanics
A rewrite is an economic bet that the cost of rebuilding from zero is lower than the cost of incrementally improving what exists. This bet almost always loses, for a structural reason.
The existing system contains what Joel Spolsky called "bug-for-bug compatibility with the real world." Every ugly conditional, every inexplicable sleep(2) before a third-party API call, every commented-out block with "DO NOT DELETE, breaks invoice generation for client X": these are not failures of engineering. They are encoded knowledge about edge cases discovered in production over years. A rewrite discards this knowledge. The new system will rediscover every edge case, one production incident at a time.
Martin Fowler's strangler fig pattern exists precisely because rewrites fail so often. You build the new system incrementally around the old one, routing traffic gradually, replacing components one at a time. It is slower. It is less emotionally satisfying. It preserves the knowledge. Stripe has operated this way for over a decade, migrating core infrastructure from Ruby to a service-oriented architecture without stopping feature development. Shopify did the same, componentizing their Rails monolith rather than rewriting it.
The fintech's Go rewrite, incidentally, had its own dragon: a 300-line service mesh configuration that nobody wanted to touch. New language, same mess. Turns out complexity is not a property of the language. It is a property of the problem.
Where Tuka comes in
Tukaram's image is domestic and precise. The woman is not wrong to be angry at her neighbor. The anger might be entirely justified. But she leaves her own house to pursue it, and while she is gone, the dogs fill the space she abandoned. The damage is not where the anger is aimed. It is at home.
This is the exact mechanics of a rewrite. The moment you stop shipping on the working system, you are not fixing the neighbor. You are losing your home. Tukaram names the cost precisely: "वायांच्या रागे फेडिले सावले" (in pointless anger, you destroyed your own shade). The shade is not a luxury. It is the thing keeping you alive: your working product, your paying customers, your market position. Two competitors shipped the features those customers wanted while the fintech team was busy being angry at Django.
What I would actually do
Ban the phrase "rewrite from scratch" from architecture proposals. If an engineer wants to replace a system, they must propose a strangler fig migration: identify the first component to extract, define the routing strategy (feature flags via LaunchDarkly or Split), and commit to keeping the old system shipping in parallel. The first extraction should take no more than six weeks. If you cannot extract one component in six weeks, your new architecture is not simpler; it is just younger. Protect 80% of engineering capacity for feature development. Your customers do not care about your architecture. They care whether you shipped the thing they asked for while you were busy being angry at the codebase.
Chetan Dhandal