Software project rescue vs starting over: how to decide

Your software has problems. Maybe your developer left. Maybe the system is slow, buggy, or can't handle what you need it to do next. Maybe it was built with AI tools and now nobody can maintain it. Whatever the reason, you're staring at the same question every business owner in this situation eventually faces: do we try to fix what we have, or do we scrap it and start over?

It feels like a 50/50 coin flip, but it isn't. The data overwhelmingly favors one option in most situations, and getting this wrong is one of the most expensive mistakes a company can make.

The math most people never see

In 2000, Joel Spolsky wrote a famous essay arguing that rewriting software from scratch is "the single worst strategic mistake" a company can make. His example was Netscape, which spent three years rebuilding its browser while Internet Explorer ate its market share. The company never recovered.

Twenty-six years later, the data says he was mostly right.

A study of 94 modernization projects found that full rewrites succeeded only 21% of the time. Not "came in a little over budget" failed. Failed as in canceled, wildly over budget, or delivered something that didn't work. 67% of rewrites exceeded their budget by 50% or more. The worst case in the study: $8.7 million spent over 31 months with zero percent of the intended functionality delivered.

Rescue and refactoring, by contrast, succeeded 68% of the time and met budget targets 85% of the time.

The median cost numbers are striking too. Across those 94 projects, rescue and refactoring came in at a median cost of $240,000 with a 5.2-month timeline. Full rewrites: $2.1 million median cost, 19.4 months median timeline. Even accounting for the fact that some of those rewrites were larger and more complex systems, the ratio is hard to argue with.

These numbers may be bigger than your project. If you're running a $50,000 to $200,000 application, scale accordingly. The ratios tend to hold: fixing usually costs 30 to 50 percent of what rebuilding would cost, and it takes less than half the time.

Why rewrites fail so often

The impulse to start over makes intuitive sense. Clean slate, modern tools, no more dealing with someone else's messy code. But three things consistently kill rewrites.

The invisible features problem. Your existing software does more than you think it does. Every edge case, every workaround, every weird little behavior that handles a specific customer's data in a specific way is a feature, even if nobody documented it. When you rewrite, you have to rediscover and rebuild every one of those. The ones you miss become bugs that your customers find after launch.

Spolsky put it this way: it's harder to read code than to write it. Old code looks ugly because it's full of bug fixes and patches that represent years of accumulated knowledge. That "ugly" code works. Rewriting it means throwing away everything you learned the hard way.

The two-system problem. During a rewrite, you're running the old system and building the new one at the same time. That means paying for two systems, maintaining two systems, and keeping the old one alive while the new one catches up. Research shows this parallel period lasts 18 to 36 months. That's a year and a half to three years of double maintenance that most cost estimates conveniently leave out.

The moving target. Your business doesn't stop while the rewrite is happening. Customers want new features. The market changes. Regulations shift. The new system has to hit a moving target, which means it's never quite done, which means the timeline keeps stretching, which means the budget keeps growing.

When rescue makes sense (most of the time)

Rescue is the right call when the following things are true:

The application works and serves customers today. It might be slow. It might have bugs. It might be missing features. But it runs, people use it, and it generates value. That means you have a foundation to build on, not rubble to clear away.

You have the source code. Not just the running application, but the actual code that produces it. If it's in a repository you can access, a new team can read it, understand it, and start fixing things. If you don't have the source code, read our guide on what to do in the first 48 hours because access recovery is step one.

The technology is still supported. If the code is written in a language and framework that's still actively maintained (React, .NET, Node.js, Python, PHP with a modern framework, Java, etc.), rescue is almost always viable. Developers can work with it. Security patches are still being released. Libraries are still being updated.

The core architecture is sound. A professional code audit will tell you this. If the basic structure of the application makes sense and the problems are in specific areas (security holes, bad integrations, missing features, poor performance in certain places), those are fixable without touching the whole system.

You need results in months, not years. Rescue projects move faster because you're fixing what's broken instead of rebuilding what already works. If you need the system stable and improved in three to six months, rescue is likely your only realistic path.

When starting over actually makes sense

There are real situations where rebuilding is the right call. They're less common than people think, but they exist.

The technology is dead. If the application is built on Classic ASP, FoxPro, Visual Basic 6, ColdFusion, or another framework that's no longer maintained, finding developers who can work on it is expensive and getting more expensive every year. Security patches stopped long ago. At some point the cost of keeping the lights on exceeds the cost of rebuilding on something modern. This is the clearest case for a rewrite.

The architecture is fundamentally broken. This is different from "the code is messy." Messy code can be cleaned up. But if the application was built without any real structure, with no separation between the database, the business logic, and the user interface, and if changing anything anywhere breaks things everywhere, the architecture itself is the problem. You can't rescue a foundation. If the audit comes back and says 70% or more of the code needs to be rewritten, you're doing a rebuild whether you call it one or not.

The requirements have changed completely. If your business has evolved so much that the software no longer matches what you do, and the gap isn't "we need more features" but "this system was designed for a completely different business model," then the existing code is solving the wrong problem. Fixing it won't help because there's nothing to fix. You need a system designed for what you actually do now.

You have nothing. No source code, no server access, no way to recover either one. If the only artifact you have is a running application you can look at but can't access the guts of, the "rescue vs rebuild" question is already answered. You're building from scratch, using the existing system as a reference for what the new one should do.

The option nobody talks about: fix it in pieces

Most articles frame this as a binary choice. Fix everything or rebuild everything. But there's a third option that works well for a lot of businesses: replace the worst parts while keeping the rest.

In software this is sometimes called the Strangler Fig pattern, named after trees that grow around an existing tree and gradually replace it. In plain English, it means: identify the part of the system that's causing the most pain, rebuild just that part using modern tools, connect it to the existing system, and repeat with the next painful part.

This approach has three advantages. First, you get value immediately. You don't have to wait 19 months for a complete rebuild. You fix the worst thing first and the improvement shows up in weeks or months. Second, the risk is contained. If the rebuild of one piece goes sideways, the rest of the system is still running. Third, you spread the cost over time instead of writing one massive check.

The trade-off is complexity. For a while, you're running a hybrid system where some parts are old and some parts are new, and they have to talk to each other. That integration work isn't free. But for most mid-sized applications, it's less expensive and less risky than a clean-slate rebuild.

The special case: AI-built applications

There's a growing category of software that doesn't fit neatly into the traditional rescue-vs-rebuild framework. These are applications built with AI coding tools like Cursor, Bolt, Replit Agent, or ChatGPT. Someone prompted an AI to build their app, it worked, and now it's in production serving real customers.

The problem is that these codebases were never designed. The AI generated whatever code satisfied the prompt, with no consideration for how the pieces fit together, how the system would be maintained, or whether it was secure. Research analyzing 8.1 million pull requests found that AI-generated code accumulates technical debt at roughly three times the rate of human-written code.

The rescue-vs-rebuild logic still applies, though. If the app works, serves customers, and is built on a supported framework (most AI tools generate React, Next.js, or Python), the code is salvageable. It just needs more cleanup than a typical rescue. The security issues tend to be worse, the architecture tends to be messier, and the lack of tests means changes carry more risk. But the core functionality is there, and that's worth preserving.

If you're in this situation, we've written specifically about the problems with vibe-coded applications and what the cleanup process looks like.

A simple diagnostic: five questions to answer before you decide

Before you commit to rescue or rebuild, answer these five questions. If you can't answer them yourself, a code audit ($2,000 to $5,000, a few days of work) will give you the answers.

1. Does the application work today? Not perfectly. Not without bugs. But does it run and serve its core purpose? If yes, you have something to rescue. If no, and it never really worked, you may be looking at a rebuild or a finish-the-job situation.

2. Do you have the source code? If yes, rescue is on the table. If no, you need to recover access first. If the code is truly gone, you're rebuilding.

3. Is the framework still alive? Google the main technology. Is it still releasing updates? Are developers still using it? Can you find job postings that mention it? If yes, the technology isn't the problem. If it's been deprecated or abandoned, the clock is ticking and a rebuild may be inevitable.

4. Where is the pain? Is the problem everywhere (the whole thing is slow, nothing works right, every change breaks something else) or is it concentrated (one module is broken, one integration doesn't work, one part of the system is insecure)? Concentrated pain points to rescue. "Everything is broken" might point to rebuild, but get an audit first because "everything is broken" is often a perception problem, not a code problem.

5. What's the business timeline? Do you need this fixed in three months or can you afford to wait 18? Rescue moves faster. If the business can't survive 12 or more months of parallel development while a rewrite happens, rescue is your only realistic option regardless of what the code looks like.

The sunk cost trap

There's one more thing worth naming because it derails a lot of these decisions. You've already spent money. Maybe a lot of money. And that money feels wasted if you don't finish what was started.

That feeling is the sunk cost fallacy, and it pushes people in both directions. Sometimes it makes you keep pouring money into a rescue when the code truly isn't worth saving, because walking away feels like admitting the original investment was a mistake. Sometimes it pushes you toward a rebuild for the opposite reason: you're so frustrated with what you have that you want to burn it down and pretend the first attempt never happened.

Neither reaction is a strategy. The money you already spent is gone regardless of what you do next. The only question that matters is: given what you have right now, what's the cheapest, fastest path to software that works the way your business needs it to? Sometimes the answer is rescue. Sometimes it's rebuild. Sometimes it's the hybrid approach. But the answer should never be driven by the desire to justify or punish a past decision.

What to do right now

If you're trying to make this decision, here's the sequence:

Step 1: Secure your access. Make sure you have the code, the hosting credentials, and the domain. If your developer disappeared, start here.

Step 2: Get an independent code audit. Not from the company that wants to sell you a rebuild, and not from the team that wrote the original code. An independent assessment from someone who has no financial interest in the outcome. This is the single best investment you can make right now because it turns guessing into knowing.

Step 3: Make the decision with data. Once the audit tells you what you're working with, use the five diagnostic questions above. The answer will be clearer than you expect.

The research says rescue works most of the time. But "most of the time" isn't "every time." Get the assessment first. Then decide.