“Our developer disappeared and the project is stuck.” If your daily work runs on that software (the scheduling app, the customer portal, the tool the warehouse uses every shift), this guide covers what to do if your developer disappears. Whether a freelance developer stopped responding, an agency abandoned your project or your last developer left the project unfinished, the order is the same: access, ownership, handover, then a decision about the code.
Before you assume the worst
People get sick and miss emails. Send one short written message through every channel you’ve used, ask for a reply by a specific date and keep a copy. Start on access while you wait; securing your own accounts harms no one.
First 48 hours: secure everything you can still reach
Start with access, not code. Anything that sits in the developer’s personal accounts, or renews on their credit card, can lapse without warning. Work through these in order:
- Domain and DNS. Log into your domain registrar. Check that the registrant contact is your company, note the expiration date and make sure auto-renew uses a company card. If the domain lapses, your website and email on that domain can stop working. ICANN, which coordinates domain names, expects registrants to keep their contact details accurate and up to date, so fix them while you’re there.
- Hosting and cloud accounts. Find out where the application runs (AWS, a hosting company, a server in your office) and whose name and card the account is under. If you can log in, add a second administrator from your company.
- Code repository. Find out where the code lives (GitHub, GitLab, Bitbucket or a server) and whether it’s in your company’s organization or the developer’s personal account. If you have any access at all, download a full copy today.
- Database and backups. Confirm you have an administrator login, find out where backups are stored and take a fresh backup or export now.
- App store accounts. If there’s a mobile app, check who the Account Holder is on the Apple developer account and who owns the Google Play developer account.
- Outside services and API keys. List every service the software talks to: payments, email sending, text messages, maps, analytics. For each one, note whose login it is.
- Shared passwords. Move every password the developer shared, from documents, spreadsheets or vaults, into a password manager your company controls.
Keep a simple access log
One row per system: what it is, the login address, whose name and card it’s under, and one of three answers: in our account, they have it or don’t know. Every “don’t know” becomes a question in your handover request. The software handover checklist uses the same three answers.
If you can’t log in at all
Gather invoices, business registration documents and card statements that show your company paid. Then contact the registrar’s and hosting provider’s support teams as the business owner or billing holder and ask what they need. Each provider runs its own recovery process and decides what it accepts, so start early, especially if a renewal date is close.
Find out what you actually own: code, accounts, IP
There are two separate questions. Who controls the accounts is practical, and you answered most of it above. Who owns the copyright in the code is legal. Logging into a repository doesn’t settle the legal question, and owning the copyright doesn’t get you into an account someone else controls.
Pull out everything you signed: the contract, statement of work, proposal, invoices and any emails that changed the terms. Look for:
- An IP assignment or “work made for hire” clause that says the code belongs to your company
- When ownership transfers: as the work is created, on delivery or only after final payment
- Source code delivery: whether the developer must hand over the code, and in what form
- Third-party components: paid libraries, themes or plugins, and whose name the licenses are in
- Termination terms: notice periods and what each side owes if the work stops
Why the clause matters: under the U.S. Copyright Act, work commissioned from an outside contractor counts as “made for hire” only if it falls into one of nine listed categories and both parties sign a written agreement saying so. The U.S. Copyright Office lists those categories in Circular 30: Works Made for Hire, and computer programs aren’t one of them. That makes a clear written assignment to your company worth looking for.
This isn’t legal advice
Ownership depends on your contract, how the developer was engaged and the law that applies to you. Take the contract to your attorney before you send anything that threatens action or refuses payment.
Ask for a proper handover: what to request
Even if the developer has gone quiet, send a written handover request. It creates a record and gives them an easy way to respond. Keep it calm and specific, list exactly what you need and set a reply-by date.
Two platform details are worth knowing. On GitHub, only someone with administrator access can transfer a repository, and the original owner is added as a collaborator on the transferred repository, so remove that access once the code is in your organization. Apple and Google both require the current account holder to start an app transfer and the receiving account to accept it (see Apple’s app transfer overview and Google’s guide to transferring apps). If your app sits in the developer’s personal store account, the standard transfer needs their cooperation.
Our software handover checklist writes the request for you: tick off what you have and it builds a numbered email with ownership-transfer wording and your reply-by date. If the developer is unreachable, it gives you an ordered recovery plan instead. Nothing you type is sent anywhere unless you choose to send it to us.
Missing access to the code or hosting?
Your first call is with an engineer, who will go through what you can reach, what’s missing and what to do first. NDAs welcome.
Change passwords and rotate keys
Once an account is in your hands, close every door the old developer could still use. This isn’t an accusation; it’s standard practice whenever someone with access leaves.
- Change passwords on every account they used, starting with the registrar, hosting, email and code repository.
- Turn on two-factor authentication with an authenticator or phone your company controls, and keep the backup codes in the company password manager.
- Remove their user accounts from the repository, hosting console, app stores, analytics and the application’s own admin screens.
- Rotate API keys and secrets: payment processor, email and text-message services, cloud access keys, database passwords, and server or deploy keys.
- Look for leftover access: forwarding rules on shared mailboxes, server login keys, admin users created for testing, and scheduled jobs that send data somewhere you don’t recognize.
Moving the repository doesn’t lock anyone out by itself. GitHub’s transfer documentation notes that secrets and deploy keys stay associated with a repository after a transfer, so they still need rotating.
Rotate keys without taking the system down
If you revoke an old key before the new one is in the application’s configuration, payments, emails or logins can stop. If you don’t know where a key is used, have an engineer rotate it with you at a quiet time and test the affected features straight after.
Get an assessment before anyone writes more code
It’s tempting to hire the first developer who says they can finish it. Hold off. A new team building on code nobody has examined inherits every problem it can’t see, and you pay for each one later.
An assessment should answer these questions in plain English:
- Does the code in the repository match what’s running in production?
- Can someone new build and run it from a fresh copy, using written steps?
- What’s finished, what’s half-built and what’s missing, compared with what you were told?
- Where are the security risks, such as keys stored in the code or frameworks that no longer get security updates?
- Do backups run, and does a backup actually restore?
- What would it take to release one small change safely?
Example (hypothetical, not client data)
A distributor’s order-entry app is “almost done,” says the developer’s last status email. The new engineer finds the repository is months behind production; the latest changes exist only on the server. The first task isn’t a feature. It’s copying the production code into the company’s repository so nothing else is lost.
Don’t pay a large final invoice before you have access
If the developer resurfaces with a final invoice, ask for the handover to happen alongside payment: code in your repository, accounts in your name, and a deployment someone else has run from the written steps. Once the money is gone, so is most of your leverage. Your contract may set payment terms, so check with your attorney before holding anything back.
Finish, fix or rebuild: how to decide
The assessment tells you what you have; this table turns it into a decision. Decide one part at a time, because one system can hold a module worth finishing next to one worth replacing.
Be wary of anyone who recommends a full rewrite before they’ve run the code. Starting over throws away the parts that work and the business rules buried in them. Before you agree to a plan, ask:
- What will you keep, and why?
- What’s the smallest change you’ll release first to prove you can deploy it safely?
- What happens to our existing data?
- What will you write down so we never depend on one person again?
Example (hypothetical, not client data)
A service company’s dispatch app works, but deployments run from the old developer’s laptop and two API keys sit in the source code. The call: fix the release path and move the keys first, then finish the three features still on the list. Nothing gets rewritten.
If you’re weighing a larger rewrite, the rewrite-or-refactor scorecard scores value, pressure, risk, data and readiness and gives a recommended path with the reasons behind it. Making this call one piece at a time is also how we approach software project rescue.
How to make sure it never happens again
Your next developer could be excellent and still get sick, change jobs or close up shop. Set things up so the software doesn’t depend on one person:
- Every account in your company’s name. Registrar, hosting, repository, app stores and outside services use company email addresses and a company card. Developers get their own logins, never the master account.
- Documentation that stays with you. Setup and deployment steps, an architecture overview and a list of outside services live in your repository; passwords live in a company password manager.
- Proof, not promises. From time to time, have someone other than the original developer deploy to a staging copy from the written steps, and restore a backup. If either fails, you’ve found the gap while it’s still easy to close.
- Working software you can see. Judge progress by what you can log into, not by percent-complete estimates. Our guide to the signs your software project is failing includes five tests you can run without reading code.
- A team that stays after launch. Software your operations run on needs security updates, checked backups and someone who answers when it breaks. Plan for that before launch, whether it’s your own staff or an outside maintenance and support team.
If your developer hasn’t vanished but you want to move on, read how to switch software developers mid-project, the planned version of this guide. More plain-language help on rescuing, modernizing and maintaining software is in our guides.
Need a team to take it from here?
We take over software someone else wrote. You talk directly to the U.S.-based engineers doing the work, and NDAs are welcome.