Can an agency rescue an unfinished software project?

In most cases, yes — but "rescued" can mean three very different things, and naming which one you're buying prevents the biggest disappointments.

The first meaning is finish it as-is: the build is 70–90% done, fundamentally sound, and just needs someone to close it out. The second is salvage and continue: parts are usable, parts aren't, and the agency keeps what works while replacing the broken pieces. The third is restart with the knowledge intact: the code itself is beyond saving, but the requirements, design, data, and lessons from the first attempt are real value that carries forward into a faster, cleaner second build.

The trap is assuming you're buying the first when you're actually buying the third. An owner who's already spent $30,000 wants to hear "we'll just finish it," and a less honest shop will tell them that to win the job — then quietly rewrite everything while billing for a "finish." That's how rescues turn into the same death spiral that killed the first attempt.

The honest version is sequencing. No competent agency can tell you which of the three you're in until they've looked at the actual code, run it, and traced how it's deployed. So the real first question isn't "can you rescue it?" — to which any agency can say yes — but "will you audit it first and tell me the truth about which kind of rescue this is, before I commit to building?" If the answer is a confident quote for a finished product before anyone has opened your repository, be careful. The unknowns are the whole problem, and a number that ignores them is a number that will change.

The audit is the deliverable that de-risks everything else, and it covers far more than "is the code good." It's a structured inventory of what you own, what works, and what's hiding.

First, can it even be run? A surprising number of stalled projects can't be started on a fresh machine — missing environment variables, undocumented setup steps, dependencies that no longer install. Getting the thing to boot is itself a diagnostic: if the original developer left no path to run it, that tells you about how it was built.

Second, the code and architecture. Is it a sensible structure or a tangle? Are there tests? Is it built on current, supported frameworks and libraries, or on versions that are already end-of-life and a security liability? Roughly how much of the intended functionality actually exists versus is stubbed out or faked in a demo?

Third, the data and integrations. Where does the database live, can you export it, and is the schema coherent? Which third-party services (payments, auth, email, maps, APIs) are wired in, and are those accounts yours?

Fourth, security and infrastructure. Exposed secrets in the code, hardcoded credentials, who controls the hosting and domain, and whether anything is one expired account away from going dark.

The output should be plain-language: here's what you have, here's what's solid, here's what's risky, here's the realistic effort to finish versus rebuild — with a recommendation and the reasoning, not just a verdict. That document is yours to keep and to take to any developer, which is exactly why a transparent agency is happy to produce it as a standalone piece of work.

The decision isn't ideological — good engineers don't default to "rewrite everything" or "never rewrite." It's made module by module, weighing what the existing code encodes against what it would cost to keep working with it.

The strongest argument for keeping inherited code is that it already contains answers. Even ugly, undocumented code captures real business rules, edge cases, and decisions someone made for a reason — the discount logic, the tax handling, the weird exception for one customer type. Throw it out and you don't just lose the code; you lose that hard-won knowledge and have to rediscover every edge case in production, on real users. That's why a total rewrite is rarely the right first move, and why agencies that reflexively pitch "we'll start fresh" are often optimizing for their own comfort over your budget.

The arguments for rewriting a piece are concrete: it's built on a framework that's no longer supported, it has security flaws that can't be patched in place, it's so tangled that changing one thing breaks three others, or it implements something so incorrectly that fixing it costs more than redoing it. The honest test is forward cost — not "is this code good?" but "is it cheaper to finish from here or from scratch, including the risk of each path?"

In practice most real rescues are hybrids. The data model and core logic get kept and cleaned; a broken auth or payment integration gets replaced with a current one; the half-finished frontend gets rebuilt on something maintainable. A good agency shows you that map — keep this, fix this, replace this, and why — so you're approving a plan you understand, not handing over a blank cheque and hoping.

More rescues stall on missing logins than on bad code, so the unglamorous first task is recovering control of your own project. Before meaningful work can start, you need the source code repository, the hosting and servers, the domain registrar, the database, and every third-party account the software depends on — payments, email, authentication, APIs. When a developer leaves on bad terms or simply stops responding, these are often scattered across accounts you've never seen.

Work through it methodically. The domain registrar and DNS are the highest-priority recovery, because losing the domain can take the whole product and its email offline. The code repository is next — if it's on GitHub, GitLab, or Bitbucket under the developer's personal account, you need it transferred or, at minimum, a complete export. Then hosting, the database (with a verified export you can actually open), and the API keys for any paid services. Reset every credential you can the moment you have access.

This is also the moment to fix the structural mistake that created the risk in the first place. Going forward, every account should be created in your name, on your email, with you as owner and the agency added as a collaborator. That's the same ownership principle that should govern your ad accounts, analytics, and website: vendors get access, never ownership, so that changing providers costs you nothing but a permission revoke. An agency that wants to spin your rescued software up on infrastructure you can't log into or export from is rebuilding the exact trap you're trying to escape — politely decline. The goal of a rescue isn't just a finished product; it's a finished product you fully control, so you're never stranded by one person's silence again.