Best Fruit is Forbidden
The idea of rewriting everything from scratch is tempting clean code, faster builds, fresh tech. But clean slates come with real costs. Here's a more honest take on why backend rewrites feel right, but often aren't.
Every couple of weeks, someone on the team says it.
"What if we move this to a new service?"
"This would be so much cleaner in TypeScript."
"We're spending more time fixing than building - should we just start over?"
And honestly, it makes sense. When you're knee-deep in a system that's grown messy over time, the idea of a clean rewrite feels like the responsible thing. You want to make it better for everyone. You want it to feel good to work in.
I've had the same thought. Many times. But here's where things get tricky. The rewrite often sounds like it'll speed things up. And sometimes, it can. Better APIs, stricter typing, a structure that actually reflects how the system works today instead of how it was imagined two years ago. But backend velocity isn't just about cleaner code. It's also about shared understanding, muscle memory, confidence. A clean slate wipes all of that out. What's fast for one person can be confusing for five others.
We don't always realize how much context lives in the old mess. Why something was hacked together in a weird way. Why that timeout exists. Why we check for a specific edge case that no one remembers until it breaks in production.
That context doesn't live in the code. It lives in the people. And when you rewrite without preserving it, you're not just cleaning - you're erasing. That's where rewrites get dangerous. Not because your instinct is wrong - it's usually right. But because the hidden costs sneak up after you've committed.
I've seen rewrites stretch timelines, fragment teams, and quietly reduce velocity.
It's not that the code got worse. It's that no one else wanted to touch it. Or knew how. Or had time to rebuild all the internal tooling and monitoring and infra glue that held the old system together.
The rewrite looked great in the pull request. But it didn't help the team move faster. Not really. So what do we do instead? We fix what's painful. Bit by bit. Break out the part that's hurting most. Add one test that actually matters. Rename things so they don't feel like a riddle. Document the edge case that keeps biting people.
There are times to rewrite. I've greenlit a few. But even then, we were careful. We ran the old and new systems together. We migrated slowly. We shared context as we went. It wasn't fun. It wasn't fast. But it worked.
If you're a developer pitching a rewrite, I get it. It's not about ego. It's about wanting to work in an environment that feels sane, that makes sense, that doesn't make you question your abilities every time something breaks. But the clean rewrite isn't always the best way there. Sometimes the mess is worth living with, just long enough to understand it.
Best fruit is forbidden. But you can still make lunch.
