A practical framework for deciding whether to fix your existing software or rebuild it from scratch — including the questions to ask, the cost factors to consider, and when each option is clearly right.
"Should we fix it or rebuild it?" is one of the most common questions in software — and one of the most emotionally loaded.
On the fix side: sunk cost. You've already paid for this code. Throwing it away feels like wasting money.
On the rebuild side: clean slate appeal. Start fresh, do it right, no more fighting with legacy decisions.
Both instincts are wrong. The right answer comes from data, not feelings.
What will it cost to get to a working, maintainable product — fix path vs rebuild path?
Not "how much have we spent." Not "what would feel better." What does it cost from here.
That requires an honest assessment of the current codebase.
Fix the existing software when:
The core architecture is sound. The fundamental design decisions — data model, system structure, API design — are reasonable. Problems are localized to specific areas rather than distributed throughout.
Bugs are identifiable and contained. You can point to specific things that are broken and understand why. The fixes don't cascade into other breakages across the system.
The codebase is navigable. A developer can onboard in 1–2 days and understand what's happening. There's documentation, or the code is self-documenting enough.
Test coverage exists. Even partial. Tests mean changes can be made with confidence. Without them, every fix is a gamble.
The fix cost is less than 30% of a rebuild. If fixing the specific problems costs ₹5L and a rebuild would cost ₹20L, fix. The margin is large enough to absorb surprises.
Rebuild when:
The data model is wrong. The most expensive problems to fix in software are bad data models. If the core tables and relationships don't reflect how the business actually works, you're fighting the structure every time you build something new. This doesn't get cheaper to fix over time.
Every change breaks something else. When the codebase has no clear separation of concerns — when changing how payments work also breaks how notifications work — you're dealing with fundamental architectural coupling. Untangling it costs as much as rebuilding.
Nobody understands how it works. If the original developer is gone and no one can explain why key parts of the system do what they do, every change is guesswork. The risk premium on every future change is enormous.
The tech stack is obsolete or unsupported. Continuing to build on a framework or language version that is end-of-life means paying an increasing security and compatibility tax forever. At some point a rebuild on a supported stack is cheaper than maintenance on a dead one.
Security problems are structural, not incidental. If sensitive data is poorly protected by design — not because of a missed validation somewhere, but because the architecture doesn't enforce boundaries — patching is treating symptoms.
The fix cost exceeds 50% of a rebuild. If fixing the existing problems would cost ₹15L and a rebuild would cost ₹20L, rebuild. You'll have a better foundation for 25% more cost.
Most projects fall between "clearly fix" and "clearly rebuild." The pragmatic option is often a partial rebuild:
A partial rebuild uses the existing data model (if it's sound) while rebuilding the code that operates on it. This is faster than a full rebuild and avoids the problems of the existing codebase.
Answer these questions:
| Question | Fix if... | Rebuild if... |
|---|---|---|
| Can a developer onboard in 2 days? | Yes | No — nobody understands it |
| Are problems localized? | Yes, to specific areas | No — widespread |
| Does the data model make sense? | Yes | No — fundamentally wrong |
| Are there automated tests? | Yes, meaningful coverage | No, or they don't pass |
| Does changing one thing break others? | Rarely | Regularly |
| Is the tech stack current? | Yes, supported | No, end-of-life or abandoned |
| Fix cost vs rebuild cost | Fix < 30% of rebuild | Fix > 50% of rebuild |
If you get 5+ "fix" answers: fix it. If you get 5+ "rebuild" answers: rebuild it. If it's mixed: consider a partial rebuild focused on the specific areas that scored "rebuild."
You can't make this decision without honest cost estimates for both paths. Most developers, when asked to estimate either option, will anchor to whichever they're being asked to do. Ask for both — "how much to fix it, and how much to rebuild it" — and get both numbers independently if possible.
The ratio matters more than the absolute numbers. A ₹3L fix vs ₹15L rebuild is an easy decision. A ₹12L fix vs ₹15L rebuild is worth thinking about carefully — you're paying 80% of rebuild cost for a worse foundation.
Rebuilds have a failure mode. They start as a disciplined re-implementation of what exists, then scope creep sets in. "Since we're rebuilding anyway, let's also add X." Then Y. Then Z.
The rebuild that was supposed to take 6 weeks takes 6 months because it became a new product development project in disguise.
If you rebuild: rebuild what exists, then add new features separately after the rebuild is stable. The discipline to resist scope creep during a rebuild is the difference between a successful rebuild and an expensive repeat of the original problem.
The worst basis for this decision is the opinion of the person who will be doing the work. They have an incentive — conscious or not — to recommend whichever option is more work.
Get an independent technical audit first. Someone with no stake in the outcome who can tell you honestly what the codebase is worth rescuing.
Hunchbite offers a free audit: we assess the codebase, give you an honest fix-vs-rebuild recommendation with cost estimates for both paths, and you decide with real data.
Call +91 90358 61690 · Book a free call · Contact form
If this guide resonated with your situation, let's talk. We offer a free 30-minute discovery call — no pitch, just honest advice on your specific project.
A practical guide for business owners whose developer has gone silent, quit, or become unresponsive — how to secure your code, assess the damage, and get your project back on track.
8 min readRescuing SoftwareYour developer went silent. Your project is half-built. You don't know what state the code is in. This is the step-by-step guide to recovering your project and getting back on track.
10 min read