Usually yes. A capable agency can take over a stalled or abandoned build, audit what exists, and decide what to keep, fix, or rewrite. Success depends less on the project's state and more on getting access to the code, infrastructure, and accounts — and an honest assessment before any rescue work begins.
- The first deliverable of any rescue is a code and infrastructure audit — not new features. You're paying to find out what's actually there before anyone commits to a fix-vs-rewrite decision.
- Access is the real bottleneck. Most rescues stall not on code quality but on missing logins: the repository, hosting, domain registrar, database, and third-party API keys often sit with a former developer who has gone quiet.
- A full rewrite is rarely the right first answer. Even rough, undocumented code usually encodes business rules and edge cases that are cheaper to inherit than to rediscover from scratch.
- Custom build work is typically scoped and priced like a custom website or app — in the $15,000–$50,000+ CAD range for substantial Next.js / custom development — but a rescue is quoted only after the audit, because the unknowns are the cost.
- You should own the code, the repository, the hosting, the domain, and every account. If an agency wants to host your software on infrastructure you can't access or export, that's the same lock-in risk that stranded the last project.
- Month-to-month engagement matters more on a rescue than on a fresh build — it lets you fund the audit first, see the real state of the project, and decide whether to continue with full information.
Can It Actually Be Rescued? Almost Always — But Define "Rescued" First
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.
What the Rescue Audit Actually Looks At
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.
Keep, Fix, or Rewrite: How That Call Gets Made
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.
The Real Blocker Isn't Code — It's Access and Ownership
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.
Related questions
Start by recovering access, not writing code. Track down and secure the repository, hosting, domain registrar, database, and any third-party accounts (payments, auth, APIs), then reset the credentials. Next, commission a code-and-infrastructure audit so a new developer or agency can confirm what runs, what's salvageable, and what needs replacing. Only after that do you scope the work to finish it — and from now on, create every account in your own name so a single person's departure can never strand the project again.
Usually not as a first move. Even messy code encodes real business rules and edge cases that are expensive to rediscover from scratch. The right call is made piece by piece during the audit — keep the parts that work, replace the parts that are unsupported, insecure, or beyond repair. A full rewrite makes sense only when the existing code is genuinely cheaper to redo than to inherit, and a good agency will show you that reasoning rather than defaulting to "start fresh."
It can only be quoted accurately after the audit, because the unknowns are the cost. Substantial custom build work in Canada is typically scoped in the $15,000–$50,000+ CAD range, similar to a custom Next.js website or app, but a rescue is priced once someone has seen the actual state of the code. Be wary of a confident fixed price offered before anyone has opened your repository — that number tends to move.
It's recoverable more often than owners expect. Domains and hosting can usually be reclaimed through the registrar or provider with proof of ownership, even if a former developer set them up. Code can be re-exported from GitHub, GitLab, or Bitbucket, or in the worst case reconstructed from a live deployment. Prioritize the domain first, since losing it can take the whole product and its email offline, then work through hosting, code, and the database.
The audit is usually days to a couple of weeks, depending on how hard the project is to run and how scattered the accounts are. Finishing the work then depends entirely on what the audit finds — a build that's 85% done and structurally sound is weeks; one that needs major pieces replaced is months. The point of auditing first is that you get a realistic timeline before committing, instead of inheriting the open-ended uncertainty that usually stalled the project to begin with.
Want a second opinion on your situation?
Get a free, no-obligation proposal. We’ll look at your site and your market and tell you honestly what we’d do — and what we wouldn’t.
Get Free Proposal →