Your developer vanished: what to do in the first 48 hours

The call comes in on a Tuesday. The site is up, the app works, checkout is taking orders — and nobody at the company knows where any of it runs. The developer stopped replying three weeks ago. The domain expires in forty days, the certificate in ten, and the only person who ever typed the server password is not answering the phone.

This is not about suing anyone. Litigation is your lawyer’s problem and it will not hand you back the DNS panel. This is an operational runbook for the first 48 hours, ordered by how much risk each step removes — what to do in the first two hours, what to do on day one, and what only makes sense once the dust settles. If you only have time for the first block, do the first block. It is what stops the damage from compounding.

An orphaned project is software that keeps running in production after the only person capable of operating it left — with no transfer of access, no documentation, and nobody at the company who can ship the next deploy.

First 2 hours: inventory ownership, not code

The instinct is to open the code. It is the wrong instinct. Idle code cannot hurt you; an expired account can. The first question is not “what does this system do” — it is “what does the company actually control right now”.

Build a spreadsheet with one row per asset and three columns: whose name it is in, who can log in today, when it expires. The assets:

• The domain. Which registrar, and registered to which legal entity. This is item number one: losing the domain means losing the business, and the renewal deadline will not wait for your internal reorganisation.
• DNS. Often a different provider from the registrar. It is what points the domain at the server.
• Hosting or cloud account. Including the credit card on file. An invoice charged to the developer’s personal card is a time bomb.
• Code repository. GitHub, GitLab, Bitbucket — and under which organisation.
• Third-party services. Payment gateway, transactional email, SMS, storage, CDN, monitoring, error tracking.
• App store accounts, if you have a published mobile app.
• The database, if it lives outside the main server.

There is a distinction here that trips up a lot of people: being the registrant is not the same as having access. ICANN is explicit about this — when an organisation outsources domain management, it should still be listed as the registrant, regardless of who holds the administrative, technical or billing contact. If your company is the registrant and the developer is merely the admin contact, you have a procedural problem, solvable with paperwork. If the developer is the registrant, you have a negotiation problem. These are very different situations, and it is worth finding out which one you are in before making any other decision.

Next 6 hours: revoke access, in the right order

A former vendor holding live credentials is not a theoretical risk. It is a valid credential with no accountable owner — precisely the category that Verizon’s 2025 Data Breach Investigations Report identifies as the initial access vector in 22% of the breaches it analysed, the single most common vector in the report. No bad faith is required: their laptop gets stolen, or a password they reused shows up in a dump.

But revoking blind is like cutting coloured wires in the dark. An API key cancelled without warning takes down payments, transactional email and integrations — in production, mid-business-day. That is why the inventory comes first. With it in hand, rotate in this order:

1. Administrative access first. Cloud provider console, registrar panel, root account. That is what lets someone destroy everything else.
2. SSH keys and server deploy keys. Remove any public key that does not belong to a named person.
3. The repository. Remove the collaborator, revoke personal access tokens, disable orphaned deploy keys.
4. Database passwords and application admin panels.
5. Third-party service keys, one at a time, with someone watching production behaviour after each swap.
6. Webhooks and integrations pointing at endpoints you do not recognise.

Turn on multi-factor authentication everywhere while you are in there. And go looking for committed secrets: a .env file checked into the repository is common in small-vendor projects, and it means the credential leaks alongside the code. The same credential hygiene sits at the top of our essential WordPress security checklist — hardened login and least privilege apply to any stack, not just WordPress.

Day one: find out whether the code is complete

Only now does the code matter. The question is not “is this code good” — it is “is this code enough to run the system without them”. Four checks answer nearly everything:

• Does the repository match what is live? Compare the commit running in production against the latest commit in the repository. A divergence means somebody pushed changes straight to the server, and the difference may contain business logic that exists nowhere else.
• Can you build it from scratch? Clone it onto a clean machine and try to run it. If the build depends on a step that only ever existed in the departed developer’s head, you find out now — not on the day you need to ship an urgent fix.
• Does a backup exist, and does it restore? A backup you have never restored is an assumption, not a guarantee. Restore it into a test environment and confirm the system comes up working.
• How does a deploy happen? If the answer is “by dragging files over FTP”, you have already identified the first structural improvement.

It helps to calibrate expectations about the cost of touching inherited code. Stripe’s Developer Coefficient research found that developers spend more than 17 hours a week on maintenance, debugging and fixing bad code. The figure is from 2018 and the sample is global, but the order of magnitude is the message: maintaining undocumented code consumes the bulk of an engineering budget, not the leftovers of it. Plan next quarter accordingly — and treat maintenance as a standing habit rather than a project, the same argument we make for ongoing WordPress maintenance.

What a handover is — and how to ask for one after the fact

A project handover is the formal transfer of everything someone needs to take over the software without consulting the person who left. It is not a goodwill gesture on the last day. It is a deliverable, and it fits in a few pages.

The minimum contents:

• An inventory of accounts and credentials, with registrant details and recovery procedures.
• Repository and production environment addresses.
• The deploy procedure, written step by step, including rollback.
• External dependencies, with cost, billing cycle and support contact.
• Architecture decisions that are not obvious from the code, and why they were made.
• What tends to break, and what to do when it does.

Even with an absent vendor, send that request in writing, by email, itemised. Two things happen: sometimes they answer — disappearing is usually an unresolved conflict rather than a getaway — and it is always on record that you asked. If this turns into a dispute, that record is what documents the attempt.

Who owns the code? The default may surprise you

Here the answer varies sharply by jurisdiction, and the assumption most buyers make is wrong.

In the United States, “work made for hire” covers work by employees within the scope of their employment, plus nine specifically enumerated categories of commissioned work. As the U.S. Copyright Office sets out in Circular 30, those categories are contributions to a collective work, motion pictures and audiovisual works, translations, supplementary works, compilations, instructional texts, tests, answer material for tests, and atlases. Custom software is not on that list. So a contractor who wrote your application generally keeps the copyright unless they signed a written assignment. Paying an invoice is not an assignment.

Other jurisdictions flip the default. Brazil’s software statute, for example, assigns rights to the commissioning party absent a contrary clause. The practical instruction is the same everywhere: read the contract you signed, and if there is no assignment clause, get one before you spend money on the codebase.

One more separation worth keeping clear under pressure: owning the code does not give you the password. Copyright is a dispute resolved over months; operational access decides whether the site is up next week. Treat access as the emergency and ownership as the process.

Hiring whoever takes over: what to ask

With access recovered and the code mapped, you have to decide who runs it from here. Two practical rules.

First, commission a short, paid assessment before any long contract. Two weeks of reading the system, delivering a written risk-and-priority document, costs little and reveals a lot — including about the vendor you are evaluating.

Second, be sceptical of anyone who proposes a full rewrite in the first conversation. A rewrite is the comfortable answer for someone who does not want to read another person’s code, and it discards business rules that live nowhere else. Stabilise first. Decide later.

The clauses that prevent a second time

An orphaned project is almost never a technical failure. It is a clause nobody wrote. For the next contract:

• Every account registered to the company, on a corporate card. The vendor gets access, not ownership.
• The repository in the company’s organisation. The vendor joins as a collaborator and leaves as a former collaborator, in one click.
• A documented handover as a condition of final payment. It is the only clause that guarantees the document gets written.
• An explicit assignment of intellectual property, so you never depend on a statutory default.
• A response-time commitment and an offboarding procedure, defining what happens in the 30 days after the contract ends.

None of them costs money. They cost remembering to write them before you start — which is precisely why almost nobody does.

If you only have time for one thing today, do this one: find out who the domain is registered to and when it expires. Everything else is slower to fix, but fixable.