Rewriting software is the tech equivalent of renovating a house while you’re still living in it: messy, expensive, and risky. Most of the time, you’re better off patching the roof and replacing the wiring than bulldozing everything. But sometimes, you really do need to burn it down and start over.
In this episode of SaaS That App: Building B2B Web Applications, Daniel Cannon, Chief Innovation Officer at Delta Systems, and Nolan Alimonti, Senior Architect and Team Lead at Delta Systems, join host Justin Edwards to discuss when software rewrites make sense, how to avoid them, and real-world experiences with successful and challenging rewrites.
First, Prove You Need a Rewrite
Developers love clean slates. Founders love fresh starts. Customers love neither if it breaks what they use today. Daniel Cannon and Nolan Alimonti are clear: a rewrite should be the exception, not the plan.
Gut-checks before you grab the matches:
- Is the code unmaintainable? If adding a small feature takes weeks because everything is tightly coupled, brittle, or duct-taped together, you may have passed the point of incremental refactoring.
- Are you doing a major product pivot? If your app started life as a direct-mail tool and now needs to be a mobile-first, API-driven communications platform, forcing the old code to fit the new shape can cost more than starting fresh.
- Is the technology stranded? When a legacy stack can’t be meaningfully upgraded without heroic effort, a clean rebuild in something modern may be the fiscally responsible choice.
And a reality check for early-stage founders: “Get to your first thousand users, then let’s talk about real scalability.”
If you’re still finding product-market fit, a rewrite won’t save you. It’s a technical solution to a business problem. Prove demand first; then decide how to serve it.
The Three Flashing Red Lights
From the trenches, here are the most credible signals it might be time:
- Unmaintainability is choking the roadmap. When every change triggers hidden landmines, your feature velocity and morale tank. If developer churn is driven by “this codebase is misery,” you’re paying an invisible tax every sprint.
- Your product has outgrown Version 1’s shape. V1s that “worked for a while” but never evolved often ossify. When the business expands, the old model can’t flex, and the path to support new lines of business is a remodel too far.
- You must add a new platform or interface that the old code can’t support. A classic: shipping a mobile app when the current web app was never designed with an API. Bolting one on can be harder than rebuilding with a proper service boundary.
“Even though a codebase may be ugly, those gross edges sometimes carry hard-won lessons about the business logic.”
Translation: beware of losing institutional knowledge that only exists in gnarly queries and battle-tested edge cases. If you do rewrite, budget time to understand and carry that logic forward.
How to Rewrite Without Burning Customers or Cash
If a rebuild is necessary, approach it with precision and care rather than making broad, sweeping changes.
- Define the mission up front. Are you rebuilding the same product, better? Or reimagining the product? Ambiguity here will balloon the scope and budgets.
- Protect revenue during the transition. For apps with active users and ongoing transactions, consider implementing an intermediate solution, such as a transitional API, to route requests between old and new systems as features are migrated. While this approach can be complex, maintaining uptime is essential.
- Migrate in slices. Don’t flip a big-bang switch. Identify cohesive domains and move them one by one. Each slice should be independently testable, deployable, and reversible.
- Budget for the invisible work. Data migrations, compliance, redirects, retraining, and support all cost time and money. In many projects, the rollouts rival the rebuild itself.
Final Thoughts
Rewrites are thrilling for builders and terrifying for businesses. Do one when there’s a clear, measurable business reason: unmaintainability that strangles velocity, a strategic pivot the old shape can’t support, or a technology trapdoor you can’t stand on anymore. When you do, de-risk it: define the mission, slice the migration, keep cash flowing, and carry forward the hard-won business logic hidden in yesterday’s mess.
Daniel’s Background
Daniel Cannon is the Founder of Strive DB and Chief Innovation Officer at Delta Systems, where he drives the adoption of emerging technologies and modern development practices across the organization. A senior developer with a history of tackling thorny technical challenges, Daniel has a knack for questioning assumptions, stress-testing ideas, and finding pragmatic ways to turn cutting-edge tools into everyday solutions. His perspective on Turbo, Stimulus, and Rails comes from hands-on experience shaping how these tools are used in real-world applications and mentoring teams through the learning curve.
Nolan’s Background
Nolan Alimonti is a Senior Architect and Team Lead at Delta Systems, where he tackles complex client projects by uniting front-end speed with backend clarity. With deep experience in React and Ruby on Rails, he’s known for simplifying messy codebases, improving scalability, and steering apps toward cleaner, maintainable architecture. A hands-on specialist in modern Rails development, Nolan has led significant refactors, helping teams migrate from TurboLinks-era code to sleek, serviceable Turbo and Stimulus builds. His goal is to make apps snappier and smoother, while keeping the stack lean and intentional.
Listen to the new episode on: