The four shapes this takes
Rescue work arrives in four costumes, and it helps to know yours: the ghosted developer, paid mid-project, now unreachable, timeline imaginary; the agency that went dark, same wound, more zeros on the invoice; the 80%-done project, technically alive, functionally stuck, "two more weeks" for four months; and the undocumented handover, the code arrived, nobody can run it, and the person who could has left the country (or the profession). The service side of this, access recovery and formal takeover, lives on the takeover page. This guide is the decision manual: what rescue actually involves, how the finish-or-rebuild call gets made, and what it honestly costs.
First, the reassurance that is also true: a failed build is nearly never a total loss. Domains are recoverable, hosting is portable, databases outlive the developers who built them, and code, even bad code, usually contains salvageable parts. The businesses that genuinely lose everything are the ones that panic-purge (wipe the account, cancel the hosting, start again on a platform an ad recommended) before anyone inventoried what existed. The first rule of rescue is therefore: change nothing, delete nothing, cancel nothing, yet.
Step one is always the salvage audit
Every rescue starts with the same unglamorous inventory, and it answers one question: what actually exists, and what condition is it in? The checklist:
- Access: registrar (who holds the domain, you, or them?), hosting account, admin logins, database, repository, email. Each one you hold is leverage; each one missing is a recovery path with its own procedure. The full recovery map is the takeover page's subject.
- Code state: does it run? Does a copy exist outside the dead developer's machine? Is there version history (a repository) or just a folder named final_v2_REAL?
- Data state: the database is the crown jewels, customers, orders, content. Export it before anything else happens to the server.
- Money state: what licenses are paid and whose name are they in (themes, plugins, SaaS subscriptions)? Lapsed licenses quietly disable updates and support.
- Public state: is a half-built site visible to customers right now? That changes the urgency calculus, not the method.
The audit is scoped, fixed-fee work, a brief with what you know is enough to start, and "I don't know most of this" is the normal case, not an embarrassing one.
The salvage decision: finish it or rebuild it
The emotional answer is "finish it, I've paid enough." The honest answer weighs four things:
- Code quality. A competent half is worth finishing; a garbage fire at 90% is worth less than an honest zero. The audit grades this without sentimentality.
- Documentation. Undocumented code costs more to finish than its completeness suggests, every undocumented component taxes whoever touches it next.
- Distance to done. "80% done" is the most lied-about number in software. The real question is which 20% remains: content entry is days; unfinished payment integration is a project.
- The sunk-cost trap. Money already paid is gone regardless. The decision is only ever "which path costs least from today", finishing a bad build because of what was spent on it is how a bad build gets more expensive.
Rebuilds are chosen more often than pride allows and less often than fear suggests, the audit's job is to make it a business decision with numbers instead of a gut decision with regret.
Taking over the 80%-done project
Resuming another developer's unfinished work has a shape, and knowing it prevents the classic second failure. First comes reverse-engineering the remaining 20%, features partially built are the expensive kind, because they must be understood before they are completed (the audit feeds this directly). Then the honest conversation about discovered work: taking over code routinely reveals problems invisible from outside, and the rescue engagement is scoped so surprises become line items, not betrayals. Then a change freeze until the existing scope ships: adding features mid-rescue is how rescues fail. Finish, launch, then evolve, in that order, every time.
What a completed rescue hands over: the finished scope, working, plus the thing the last developer never gave you, documentation and ownership. Repository in your account, credentials in your name, a written map of what runs where. The handover checklist is the standard; rescue work is held to it without being asked.
The undocumented handover
Sometimes the project is "done", and unusable. The code arrived with no run instructions, the database dump has no password list, the hosting login went with the employee who managed it. Reconstruction is routine work with a boring method: get it running in a controlled environment, map what it actually is (framework, database, integrations, cron jobs, the API keys everything quietly depends on), document it, and hand back a system a competent stranger could operate, you, or the next developer, or this desk in a year. Where the handover is hostage-shaped instead of merely messy, access held by a party who will not cooperate, that is the takeover track, and it runs on proof of ownership through provider processes.
What rescue costs, honestly
Rescue pricing has a different grammar than project pricing, and distrust anyone who quotes it in one number from one email. The honest structure: the audit is fixed-fee, priced from what you can describe, and produces the inventory plus a finish-vs-rebuild recommendation. The work after the audit is scoped from what the audit found, completion, reconstruction, or a rebuild plan, because discovered work makes pre-audit quotes fiction. And the uncomfortable truth, stated plainly: rescues sometimes cost more than building fresh, because understanding someone else's unfinished code is real work. When that is the case, you will hear it at the audit stage, with the numbers that say so, not after the invoice. Context for the bands: the rates page; the cost calculator prices a fresh build for comparison.
How to never need this page
The rescue checklist inverted is the prevention list, and it costs almost nothing on the next project: everything in your name from day one (domain, hosting, accounts); a written contract with milestones you can verify and payment tied to them; repository access from the first commit, not the final invoice; a written brief so scope disputes have a referee; and staged payments that never leave you 80% paid for 80% unfinished. None of this insults a good developer, good developers hand you these things before you ask, and the vetting guide covers how to tell them from the ones who ghost.
Mid-emergency right now? Urgent triage for the live fire, the takeover page for the access recovery, or send the brief, "my developer disappeared" is a complete and workable opening line.