Rewrites are the silver bullet that never hits the target.

If you’ve ever worked in SaaS, you’ve likely heard it before:"The tech stack is outdated.""We have too much technical debt.""This architecture won’t scale—we need to start fresh!"

At first glance, it makes sense. A cleaner, modern, well-architected system should let the team move faster and deliver more, right? Except, that’s rarely what happens.

In our latest Hotfix Podcast episode, we sat down with Alex Oprescu, an engineering leader who has witnessed firsthand how rewrites derail companies, drain resources, and create more problems than they solve.

Let’s unpack why rewrites are so tempting, why they often fail spectacularly, and what SaaS companies should do instead.

Why Do Engineering Teams Push for Rewrites?

Rewrites usually start from a real problem—the product has accumulated too much complexity, development is slowing down, and technical debt is piling up. When a company scales, the initial scrappy codebase often starts feeling like a house built on shaky foundations.

But rather than fixing what’s there, engineering teams often push for a full rewrite. Why?

💡 The Fantasy of a Fresh Start – Engineers love the idea of working with a clean slate. No more legacy issues, no more messy code, just a modern, elegant system.

💡 Blame Shifting – It’s easier to say, “Our architecture is bad” than to admit, “We made poor product decisions” or “We don’t fully understand our customers.”

💡 Internal Constraints & Skill Biases – Sometimes, companies have a team skilled in a new tech stack and push for a rewrite—not because it’s needed, but because it fits their internal expertise.

💡 Chasing a False Hope – There’s a belief that a rewrite will unlock faster development, happier engineers, and better scalability—but it rarely works out that way.

The Harsh Reality: Most Rewrites Fail

🚨 They take far longer than expected. Rewriting a product isn’t just about rewriting code. It involves migrating data, ensuring feature parity, retraining users, and fixing unforeseen compatibility issues. Most teams underestimate the complexity.

🚨 They kill momentum. While engineers are busy rebuilding, the business stands still. New features are deprioritized, customers get frustrated, and competitors move ahead while you're stuck redoing work.

🚨 They don’t fix the real issue. Many teams believe rewriting their product will make it more scalable, but they ignore the core business problem—which is often not about tech, but about how the product is evolving.

🚨 They ignore customer needs. A rewrite often focuses on internal pain (engineers hating the old codebase) rather than external pain (customers struggling with the product).

The Alternative: Refactor Instead of Rewrite

Rather than tearing everything down and starting over, winning teams take a more pragmatic approach.

✔️ Assess What’s Really Broken – Is it truly the tech that’s limiting growth, or is the product itself not solving the right customer problems?

✔️ Fix in Iterations – Instead of rewriting the entire system, refactor incrementally. Break down monolithic components, optimize bottlenecks, and gradually improve the system without stopping feature development.

✔️ Retire Features Aggressively – One of the biggest reasons software becomes unmanageable is feature bloat. If customers aren’t using something, remove it instead of rebuilding it.

✔️ Know Your Business Stage – As Alex explained in the episode, teams should identify where their company is:

* Exploration phase (testing product-market fit) → Rewrites are deadly here.

* Expansion phase (scaling up fast) → You need speed, not perfection. Avoid rewrites.

* Extraction phase (optimizing an already successful product) → If you’re here, a rewrite might finally make sense—but only with clear ROI.

Rewrites Can Kill Startups—Don’t Fall for the Trap

Atlassian, Facebook, and other giants have all faced this problem. The smartest teams recognize that rewriting an average product won’t magically make it great.

🚫 If your product isn’t selling well, a rewrite won’t change that.🚫 If your company is slowing down, a rewrite won’t fix your strategy.🚫 If engineers are struggling, a rewrite won’t necessarily make them faster.

The next time your team suggests starting from scratch, ask: Are we fixing a real problem, or just running from the mess we created?

🎧 Want to hear the full discussion? Listen to our podcast episode with Alex Oprescu:

🔊 Spotify: 🔊 Apple: https://podcasts.apple.com/at/podcast...

📲 Follow us on LinkedIn for more insights:

* Christoph: https://www.linkedin.com/in/christophbodenstein/

* Stefan: https://www.linkedin.com/in/stefan-pernek-629901107/

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thehotfixpodcast.substack.com