Questions to Ask Before Agreeing to a Rewrite

“Let’s rewrite it” is rarely a technical recommendation. It’s usually a frustration signal.

I’ve been on both sides of this conversation. As the engineer who wanted to burn it down and start fresh. As the leader who had to decide whether the pain was worth the price. The rewrite is almost never as clean as it sounds in the pitch.

Before you say yes, or before the conversation even starts, here are the questions worth asking.

What specific problem does this solve that we can’t fix incrementally? Rewrites are seductive because they promise to fix everything. But “everything” isn’t a problem statement. If you can’t name the concrete pain points, you’re not solving a problem; you’re avoiding one.

What doesn’t get shipped while we’re rewriting? A rewrite isn’t free time. It’s borrowed time. Every week spent rebuilding is a week not spent on features, fixes, or the thing your customers actually asked for. Make the tradeoff explicit.

What happens if we do nothing? Sometimes the answer is “things get worse slowly.” Sometimes it’s “honestly, we’d be fine.” The urgency of a rewrite often lives more in the engineer’s head than in the system’s trajectory.

Have we tried fixing just the painful parts? Most systems aren’t uniformly broken. They have hot spots, the parts everyone dreads touching. Sometimes fixing those hot spots is 20% of the effort with 80% of the relief.

A rewrite might be the right call. But it should survive these questions first.

What’s the best rewrite decision you’ve made or avoided?