Most unfinished software projects can be rescued. That's the direct answer. But it comes with conditions attached, and they're not negotiable. Rescue is viable when a few things are true: the codebase can actually be pulled up, run, and assessed by someone other than the person who wrote it; the original requirements or intent can be reconstructed, even partially, from documentation, stakeholder memory, or just watching how the running app behaves; and there's budget set aside for a structured audit before anyone writes a single line of new feature code. When those conditions hold, a stalled project is usually a project management and process problem. Not a code problem.
There are two situations where the math tips toward a rewrite instead. First: the codebase is genuinely unreadable — no tests, no meaningful commit history, inconsistent patterns, and nobody left who can explain why anything was built the way it was. Second: the technology stack itself is the obstacle. Think a language version or framework so obsolete it can't be patched for known vulnerabilities, can't be deployed on current infrastructure, or can't be staffed because nobody's hiring for it anymore. Outside those two cases, most projects we see labeled 'unsalvageable' are actually fine. They were just never properly assessed before someone tried to jump back into building.
Why do software projects get abandoned or left unfinished in the first place?
Unfinished projects tend to fall into a handful of recurring patterns. Figuring out which one applies to your situation matters, because it points toward the right rescue approach later on, whether that ultimately means 7 signs your business has outgrown a template and needs a custom web app or something closer to a straightforward repair.
- The original developer or agency disappeared. A freelancer went dark, an agency shut down, or a contract ended abruptly, leaving the code in whatever state it was in on the last day someone touched it.
- Funding or priorities shifted. The project wasn't abandoned because it was broken — the business ran out of runway, pivoted, or reprioritized, and the work simply stopped mid-stream.
- Scope crept past the original budget. What started as a defined build grew feature by feature until the cost and timeline no longer matched what was agreed, and the relationship (or the money) ran out before the work did.
- No documentation was ever written. Decisions lived in one or two people's heads. Once those people left, the reasoning behind the architecture, the data model, and the integrations left with them.
- Technical decisions were made without any knowledge transfer. Even when documentation exists, it often doesn't capture why certain choices were made, which makes it hard for a new team to know what's safe to change.
- The code 'works' but nobody trusts it. This is common with projects that limped to a demo or soft launch but accumulated enough unexplained bugs and workarounds that stakeholders stopped believing in it, even though it technically runs.
What are the first steps to take before writing any new code?
The single most common reason rescue attempts fail is that someone skips triage and starts writing features on top of a foundation nobody has actually inspected. Before any new development happens, there's a short, concrete sequence worth following in order.
- Freeze the current state. Tag or branch the codebase exactly as it stands so there's a stable reference point to compare against and revert to if changes go wrong.
- Recover access. Track down or re-establish credentials for every repo, hosting account, database, domain registrar, third-party API, and environment the project depends on. Lost access is a surprisingly common reason rescues stall before they start.
- Run it and document reality versus claims. Get the application running locally or in a sandbox, and write down what actually works, what's broken, and what's simply missing — separate from whatever the last status report or handoff notes claimed.
- Inventory dependencies. List every library, framework, and service version in use, and check which ones are outdated, unsupported, or carrying known vulnerabilities.
- Talk to available stakeholders. Original developers, product owners, and even early users often hold undocumented context about intent and priorities that never made it into any written record. A short conversation here can save weeks of guessing later.
How do you audit an unfamiliar or abandoned codebase?
Once triage is done, a lightweight audit gives you an evidence-based picture of what you're actually working with, rather than impressions from a quick skim of the code. A useful audit checks test coverage (or the lack of it), scans for known security vulnerabilities and outdated dependencies, and compares the architecture against current best practices for that type of application. It also identifies 'hot spots' — the files and modules that change most often. That's usually where bugs concentrate and where the design is under the most strain. Grading overall code health on a simple scale, something as plain as healthy, workable, or fragile, makes the findings communicable to stakeholders who aren't going to read a dependency report line by line.
This kind of audit deserves its own detailed treatment rather than a partial summary here. We go deeper into the specific methodology, tools, and checklist in a dedicated codebase-audit piece elsewhere in this series, and the same audit logic underpins our nonprofit technology audit approach.
How do you decide between repairing, refactoring, or rewriting the existing code?
The audit findings feed directly into one decision: repair, refactor, or rewrite. The criteria are fairly plain once you have real evidence instead of guesswork.
- Repair. The architecture is fundamentally sound and specific features or bugs are the problem. Patch and stabilize rather than restructure.
- Refactor incrementally. The foundation is workable, but code quality, consistency, or test coverage is poor. Improve the code gradually while continuing to ship, rather than pausing everything to rebuild.
- Rewrite. The stack can't be supported going forward, the architecture can't scale to what the business actually needs, or the cost of understanding and safely modifying the legacy code exceeds the cost of building it again from a clean foundation.
A useful rule of thumb: compare the audit's findings against remaining budget and timeline, not against the original estimate. If stabilizing the existing code would eat most of the available budget just to reach a baseline that still needs significant further work, a rewrite is often cheaper in total, even though it feels like a bigger step backward. There's no formula that spits out a precise number here — anyone who claims otherwise is overselling the certainty of the estimate — but this comparison is usually enough to point clearly in one direction, and it's worth weighing against a realistic cost breakdown for custom software before committing either way.
How do you rebuild trust and momentum on a stalled project?
Rescuing a project is as much a human and process problem as a technical one, especially when stakeholders have already been burned once by a missed timeline or a developer who went quiet. The first step is setting a realistic, re-baselined timeline rather than reusing the original one. That original number was built on assumptions that already proved wrong; repeating it just sets up a second disappointment. From there, it's worth establishing basic engineering hygiene if it wasn't already in place, including version control discipline and a continuous integration pipeline. A proper staging environment separate from production matters too. These aren't advanced practices. They're the baseline that makes ongoing work visible and safe.
Communicating transparently about what the audit actually found, including the uncomfortable parts, is where credibility is either rebuilt or lost for good. Stakeholders who've already watched a project stall once are usually more reassured by a candid, specific account of the problems than by reassurance that everything's fine. In our experience, clients respond better to a clear 'here's what's broken and here's the plan' than to vague optimism, even when the findings aren't great, a lesson that overlaps heavily with navigating difficult conversations with clients when scope creep kicks in.
What should you look for when hiring a developer or agency to take over an unfinished project?
Taking over someone else's unfinished work is a different skill from building something new, and not every capable developer or agency has it. When evaluating who to bring in, a few criteria matter more than a general portfolio review, similar to the criteria laid out in 15 questions to ask before hiring a freelance developer.
- Direct experience with legacy takeovers. Ask for examples of projects they've inherited from someone else, not just projects they built from a blank slate — the two require different instincts.
- Willingness to do a paid discovery phase first. Anyone offering a fixed price to 'finish' your project without first auditing it is guessing, and you're paying for that guess either way.
- Honesty about what they don't know yet. A team that admits the audit might surface unknowns is more trustworthy than one that promises certainty on day one.
- Clear documentation practices going forward. Ask how they plan to document decisions this time, so the next person (or the next hire) doesn't inherit the same knowledge gap.
If you're weighing whether to bring in outside help for exactly this kind of discovery and audit phase, that's the specific work we do at BLP. We'd rather start with a paid assessment and an honest recommendation than quote a number before we've actually looked under the hood, much like the brief-first approach described in how to brief a design studio on a product build.
Key takeaways: what determines whether an unfinished project is worth saving
Most unfinished projects are recoverable, but only under specific conditions: an assessable codebase, requirements that can be reconstructed at least partially, and a budget that allows for a real audit before new development starts. When the code is genuinely unreadable with no tests, or the stack is too obsolete to secure or staff, a rewrite is usually the more honest path forward. This piece is the entry point into a broader series on rescuing and taking over software projects. Related pieces on codebase audits, legacy takeover contracts, and the rewrite-versus-refactor decision in more depth are planned as companion reading for anyone working through a specific stage of this process, including topics like seven signs your business has outgrown its spreadsheets.