Before You Agree to a Rewrite

“We need to start over.” Four words that have burned more runway than any failed marketing campaign.

At some point, almost every founder hears it. Your development team is frustrated. Features that used to take days now take weeks. Bugs multiply. And someone on the team — usually the most senior person — says the codebase is beyond saving and the only path forward is a full rewrite.

It feels decisive. It sounds like progress. It is almost always the wrong call.

Here’s why. A rewrite means rebuilding everything you already have before you can build anything new. Your competitors are shipping features while you’re recreating what your customers already expect to work. And the timeline your team estimates? Double it. I’ve never seen a rewrite finish on schedule. Not once.

The deeper problem is that the same team, the same habits, and the same pressures that created the current mess will be building the new one. A rewrite doesn’t fix how you build. It just resets the clock on when the pain shows up again.

What works instead is quieter and less satisfying: fix the system incrementally. Identify the one area that causes the most friction and isolate it. Improve it. Draw a boundary around it. Then move to the next one. It’s slower to describe but faster to deliver.

The question to ask when someone recommends a rewrite: what specific business outcome does this unlock that we can’t achieve by improving what we have? If the answer is about developer comfort rather than customer value, that’s worth a longer conversation.

Rewrites feel like a fresh start. They’re usually an expensive loop.

What’s your experience? Have you ever been through a rewrite that was worth it?