Article | Strategy

The Cost of Leaving a Software Rewrite “On the Table”

Reading time: ~ 5 minutes

There’s a pattern we keep running into.

We hear it in conversations with engineering teams. It shows up in podcast interviews with people who’ve lived through multiple generations of “the next system.” It comes up in hallway track conversations at conferences. And it surfaces when experienced engineers quietly start exploring new roles and struggle to explain, cleanly, what went wrong.

“We might rewrite this someday.”

Different companies. Different stacks. Same dynamic.

By the time teams reach out to us, they’re often at an inflection point. They’re debating whether to rewrite software they are entirely reliant on, even though it still runs the business every day. The system might be built with Rails, Ember, or something else entirely. It reflects years of real-world tradeoffs, customer pressure, and survival decisions. Some of those decisions still make sense. Some don’t. What matters is that the software works… and the team’s relationship to it has quietly deteriorated.

Once the idea of a rewrite enters the room, even casually, progress starts slowing long before anything actually breaks.

How Rewrite Talk Becomes a Drag on Momentum

Most teams never actually decide to rewrite their software. There’s no announcement. No budget. No timeline. No explicit mandate.

Instead, the idea hovers.

It shows up as banter. A half-joke in Slack. A comment in a meeting. “Honestly, we’ll probably rewrite this someday.” No one disagrees. No one commits either. The rewrite becomes a shared possibility rather than a plan.

For leaders, this is easy to miss because nothing has officially changed. But psychologically, everything has.

Once something is treated as provisional, people stop taking full responsibility for it. Not out of apathy. Out of self-preservation. When engineers believe the system is temporary, they invest less in it. They stop fixing small things. They stop deepening their understanding. They stop improving quality-of-life issues that don’t obviously pay off right now.

They’re still doing their jobs.
They’re just doing them in a waiting posture.

That posture shows up in subtle but compounding ways. Refactors get deferred. Tests feel less urgent. Documentation falls behind. Deep fixes only happen when they’re unavoidable. Engineers stop advocating for improvements when they no longer believe improvements are expected or valued.

From the outside, this can look like a lack of motivation or resistance to change. From the inside, it feels like professional disengagement. Deploys feel riskier. Reviews become more conservative. Ownership blurs. The team isn’t blocked by the codebase… they’re blocked by uncertainty about whether the work they do today will matter tomorrow.

Asking About a Rewrite Is Healthy. Leaving It Unresolved Is Not.

It’s worth saying clearly: it is healthy for teams to ask whether a rewrite is warranted periodically. Avoiding the question entirely is not stewardship. Systems age. Context changes. Sometimes replacement really is the right move.

The problem isn’t asking the question.

The problem is asking it informally, repeatedly, and never finishing the thought.

What we see most often is that teams do explore the rewrite question and land on the most common conclusion: staying put is the least risky, most pragmatic option right now. And then… nothing happens. No rationale gets written down. No decision gets shared. No alternative path is named clearly.

So the conclusion evaporates, even though the outcome remains.

That’s how rewrite fantasies linger.

A year later, someone new joins the team and makes an offhand comment: “Well, once we rewrite all this…” And unless someone responds clearly, the cycle restarts. The team slips back into provisional thinking, even though a decision was already made.

When a team decides not to rewrite, that decision needs a spine. It should be captured, shared, and reinforced. It should name the risks that were evaluated, explain why replacement wasn’t the right move, and clearly state what the team is committing to instead.

That doesn’t shut down discussion.
It shuts down drift.

Why This Pattern Shows Up So Reliably

I wrote about this more explicitly in a post describing the seven stages of tech stack adoption. The goal wasn’t to define a perfect lifecycle, but to name a familiar arc that appears once software survives long enough to matter.

Early on, teams feel momentum and optimism. The system is small, understandable, and easy to change. As the product succeeds, pressure increases. Guardrails appear. Process grows. Tradeoffs accumulate. Over time, the software becomes more capable… and heavier.

Eventually, many teams reach a stage where the system still works, but changing it feels slow, risky, or emotionally exhausting. That’s usually when rewrite talk begins to surface.

Not because the software is failing.
But because the team is tired.

For product and technical leaders, this framing can be useful. Instead of asking whether the technology is “too old,” it’s worth asking where your team would place itself along that arc. Are they engaged and investing? Cautious but confident? Or resigned and waiting?

Rewrite talk often shows up as a symptom of that last stage.

Why AI Forces This Question to the Surface

There’s an accelerant in the room right now: AI.

Many leaders are understandably looking at new tooling and thinking, “We can finally move faster. Maybe this is the moment to rebuild.” It’s not irrational to ask the question. If AI can reduce friction and speed up delivery, then yes, this is a reasonable time to re-evaluate big bets.

But this is where teams get tripped up.

AI makes it easier to start things. It does not remove the hardest parts of a rewrite. It doesn’t untangle domain complexity. It doesn’t migrate data safely. It doesn’t reproduce years of edge cases. It doesn’t eliminate the cost of running two systems in parallel during the organization's transition.

If a team already carries an unspoken “someday we’ll rewrite” vibe, AI pours fuel on it. Not because it changes the fundamentals, but because it offers a convenient story. A way to avoid stewardship while still sounding ambitious.

And if the team doesn’t answer the rewrite question themselves, someone else will. At some point, a product leader, executive, or board member will ask, “If AI makes us faster, why aren’t we rewriting this? Your team doesn’t even seem excited to maintain what we have.”

That question is coming. The best move is to get ahead of it.

How Leaders Can Reset the Dynamic

Instead of rushing to justify a rewrite, the more effective move is to change the questions being asked.

Questions like:

Are we treating this software as something we actually inhabit?
What daily friction has the team normalized?
What improvements keep getting postponed because they’re not “strategic” enough?
If nothing changed for a year, what would burn people out first?

These surface behavior and experience, not architecture.

One exercise we’ve seen work well is to ask the team to assume this is the last production codebase they will work in for the remainder of their careers. No rewrite. No replacement. Just stewardship. Then ask what they would fix first to improve quality of life, what frustrations they would finally address, and what they would stop tolerating.

The answers are rarely about frameworks. They’re about clarity, safety, and reducing unnecessary stress. Those answers are usually a better roadmap than any rewrite proposal.

A Final Reframe

Leaving a software rewrite “on the table” isn’t neutral.

It shapes behavior.
It lowers standards.
It teaches teams to wait.

Ask the rewrite question. Take it seriously. Do the analysis. But when you decide to stay put, say it out loud. Capture the rationale. Repeat it. Point to what has improved since.

What stalls teams isn’t old software.
It’s unresolved futures.

And the second act doesn’t start with new code.
It starts when leaders help their teams fully re-inhabit the systems they already depend on every day.