Developer Disappeared With Your Code: A 48-Hour Recovery Plan

If your developer disappeared with your code, spend the first 48 hours on control, not code. List every account the product depends on, recover the domain, hosting, repository and database first, back up production data, and rotate the secrets the developer held. Only then assess the code you get back and decide whether to rescue or rewrite.

This plan is for founders whose freelancer has ghosted them, whose agency has stopped answering, or whose only developer has simply gone quiet. It assumes you are not technical and may not know which accounts exist. It covers the access inventory, the order to lock things down, how to recover accounts held in someone else's name, the legal questions to take to a lawyer, and how to judge what you get back.

What should you do in the first hour?

Send one calm, written request, then start the inventory. Do not change passwords, revoke access or post about it publicly until you know which accounts you actually control.

Most disappearances are not theft. People get ill, burn out, take a full-time job or close a business, and a client project stops being anyone's priority. A polite message that asks for specific things, by a specific date, gets more back than a threat, and it creates a dated record if you need one later.

• Ask for specific items: admin access to the repository, hosting and database, the registrar login for the domain, and a list of every third-party service the app uses.
• Give a date: "by Thursday 5pm" is clearer than "as soon as possible".
• Use every channel you have once (email, chat, phone), then stop. Repeated messages read as pressure.
• Save everything: the contract, invoices, payment receipts and the message history. These are your proof of ownership with every provider below.

Hold off on revoking the developer's access for now. If deploys run on their personal token, or the database password lives only on their machine, cutting them off before you have your own admin access can take production down with nobody left who can bring it back.

Which accounts does your product depend on?

Usually nine kinds, and the domain registrar matters most because it controls everything else. Fill in this table with who owns each account today, whose email it is registered to, and whether you can log in.

Account	Why it matters	Who should own it	How to recover it if you are locked out
Domain registrar	Controls DNS, so it controls the website, email and every password-reset link	The company, as the registrant, with a company email	Look up the registrant; the registrar's support can act for the registered name holder with proof of identity and business documents
DNS provider	Points the domain at hosting and email; can be separate from the registrar	The company	If you control the registrar, change the nameservers to a DNS account you own and recreate the records
Hosting and deploy platform (Vercel, a cloud provider, a VPS)	Runs the app and holds production environment variables	A company team or organisation with two admins	Ask the account owner to transfer the project; otherwise contact support with billing proof, or redeploy into a new account you own
Code repository (GitHub, GitLab, Bitbucket)	The source code and its history	A company organisation, with the developer as a removable member	Request a transfer to your organisation; if you have no copy at all, this depends on the developer or your contract
Database	Your customers' data, which is the hardest thing to recreate	The company, inside the hosting account it owns	Through the hosting account; take a full backup the moment you have access and prove it restores
App-store accounts (Apple, Google Play)	Publishing rights for your mobile apps	A company developer account	Both stores support moving an app between developer accounts, but the current account holder normally has to start it
Payment provider (Stripe, PayPal, local gateways)	Where your revenue lands	The company, paying out to a company bank account	Contact support at once if payouts go anywhere you do not control
Email (workspace and transactional sending)	Password resets, customer receipts and sign-up emails	The company, with admin rights held by a founder	Most workspace providers let a domain owner regain admin by proving control of the domain's DNS
API keys and other services (maps, SMS, AI APIs, error tracking, analytics)	Features stop working, or keep costing money, without them	Company accounts, with keys stored in the hosting platform's environment settings	Create new accounts and keys you own, then swap them in; rotate the old ones

If a row says "the developer's personal email", that account is a single point of failure, even if the developer is still friendly. Fixing that is part of this job, not an optional extra.

What should you lock down first?

The domain first, then email, then money, then data. Whoever controls the domain can reset the password on almost every other account, so it goes at the top.

1. Domain and DNS. Make sure the company is the registrant, change the registrar password, and turn on two-factor authentication and the registrar's transfer lock.
2. Email admin. Password resets for everything else land here. Remove admin rights you did not grant.
3. Payment provider. Confirm the payout bank account is yours and that nobody else has admin rights.
4. Database backup. Take a full backup, store it outside the hosting account, and restore it once to prove it works. A backup you have never restored is a hope, not a backup.
5. Repository. Get a complete copy with history, ideally transferred into your own organisation.
6. Hosting. Add yourself as an owner and record which commit is running in production.
7. App stores. Confirm who the account holder is and start any transfer that is needed.
8. Secrets. List every key and password the app uses, where each one is configured, and only then rotate the ones the developer knew.

For every account, the end state is the same: a company-owned login on a role address such as admin@yourcompany.com, at least two admins, and two-factor authentication. Only when that is true should you remove the developer.

How do you recover an account that is in the developer's name?

With the developer's cooperation it takes minutes. Without it, you need proof that the account belongs to your business, and patience with support queues.

For domains, the rules are unusually clear. Under ICANN's Transfer Policy for generic domains such as .com, the registered name holder's authority over a transfer supersedes the administrative contact's. So the first question is who the registrant is, not who set the domain up. If the registrant is your company, the registrar can usually help you. If the registrant is the developer personally, you are in a negotiation, and the contract matters. The same policy can put a 60-day transfer lock on a domain after a change of registrant, so start early if the domain needs to move registrars.

For everything else, gather the same evidence pack before you contact support:

• Your company registration documents and a matching ID.
• Invoices or card statements showing that you paid for the account or the service.
• The contract or statement of work that names the product.
• Your dated written request to the developer, and any reply.

Some accounts cannot be recovered, only replaced. If the hosting account is personal and support will not move it, the practical route is often to deploy the code into a new account you own and repoint DNS, which is only possible once you control the domain and have the code.

What legal basics should you check?

Three documents decide how strong your position is: the contract, its IP clause, and anything that says where the code is held. This section is general information, not legal advice; take your documents to a lawyer in your own jurisdiction before you escalate.

• The contract. Does it define deliverables, handover obligations and what happens on termination? Does it require access to be returned?
• IP assignment. Do not assume that paying for code means you own it. Whether you do depends on your contract and your jurisdiction. Wording matters: a present assignment ("hereby assigns") is generally treated differently from a promise to assign in future ("will assign"). Ask a lawyer which one you have.
• Payment status. If invoices are unpaid or disputed, expect that to be raised. Paying the undisputed part in exchange for a documented handover is often faster than a dispute.
• Escrow. Source-code escrow, where a third party holds the code for release if the vendor fails, is common in larger contracts. For most small products, the simpler version works as well: the repository lives in your organisation from the first day, so there is nothing to release.

For the future, write the protections into the next contract before work starts: present-assignment IP, company-owned accounts, and code in your repository from the first commit. RAITHub's own terms assign full IP to the client through a present-assignment clause, and the security page lists how code and access are handled.

How do you assess the code you get back?

By checking whether it builds, whether it matches what is deployed, and whether anything dangerous is hiding in it. None of this requires reading the code line by line.

Check	How to do it	What a bad result looks like
It builds from a clean checkout	Run the exact install and build commands the host runs, on a fresh machine or in CI	It only builds on the developer's laptop, or needs undocumented steps
It matches production	Compare the commit deployed in hosting with the latest commit you received	Production runs code that is not in the repository at all
No secrets in the history	Run a secret scanner over the full git history, not only the latest files	Live keys committed at any point, which means they must be rotated
The database can be rebuilt	Look for migration files and replay them on an empty database	Tables were edited by hand in a dashboard and exist nowhere in code
Dependencies are current	Run the package manager's audit command	High-severity advisories, or packages years behind
Tests exist and pass	Run the test command and count the results	No tests, or tests that were switched off

Two bad results are normal. Five usually means a proper diagnostic before any new feature work. The Code Rescue Playbook describes the full 2-week diagnostic, and if the only problem is one clear bug, what it costs to hire a developer to fix a bug is the better starting point.

Should you rescue the code or rewrite it?

Usually rescue. Code that has real users encodes business rules that are easy to lose, and the data model is the most expensive thing to replace. Rewrite only when the code is a prototype nothing depends on, the platform no longer gets security fixes, or the data model contradicts how the business works.

A ghosted project adds one more factor: nobody can explain the code. That makes a rewrite tempting, because the new team would at least understand what they wrote. Resist it until a diagnostic has shown what is actually broken. The trade-offs are covered in rewrite vs refactor, and what code rescue services cost explains what a rescue should include and what moves the price.

What did RAITHub learn moving its own live site to a new domain?

That redirects only work while you control the old domain. RAITHub moved its own live website to a new domain and a new hosting setup in 2026, and every step of moving a live site to a new domain without losing search traffic depended on owning the old one.

The steps, from that move:

• Path-preserving permanent redirects. Every URL on the old domain answers with a 308 to the same path on the new one, so old links and indexed pages land on the matching page rather than the homepage. Google's site move guidance recommends permanent server-side redirects such as 301 and 308, kept in place generally for at least a year.
• One canonical host. The site picks a single host, with www, and every canonical tag, sitemap entry and structured-data ID is built from one function. That function ignores any configured value that is not the real domain, because a stale environment variable once pointed canonicals at an old preview host that no longer existed.
• Environment variables per environment. The public site URL and the auth callback URL were set explicitly for production and redeployed. The build now fails if a required production variable is missing, instead of shipping a site that half works.
• Telling search engines. A fresh sitemap and an IndexNow submission for every URL after the deploy.

It is too early to report traffic results from that move, so this post does not claim any. The lesson for a ghosted founder is simpler: if the developer keeps the old domain, none of this is possible, because you cannot redirect a domain you do not control. That is why the domain sits at the top of the lockdown list.

Why RAITHub for a ghosted project?

Because RAITHub's Code Rescue engagement starts where this plan ends: with access secured and nobody left who understands the code.

• Access first. The first step of every rescue is the access inventory above, followed by a 2-week diagnostic: codebase audit, infrastructure audit and risk register.
• Keep what works. The default is to stabilise and replace only the modules that cost you, not to rewrite.
• Stack-agnostic, founder-reviewed, and priced as a fixed written quote after a free 15-minute technical audit. RAITHub publishes no rates.
• Ownership stays with you. An NDA before you share access, full IP assignment, and runbooks at handover so you are never dependent on one person again.

When do you not need RAITHub?

• The developer answers and hands everything over cleanly. A careful handover checklist and a new developer you trust may be all you need.
• It is a legal dispute first. If ownership of the code is contested, see a lawyer before paying anyone to work on it.
• The product is a prototype with no users. Rebuilding cleanly may cost less than recovering it.
• The site runs on a hosted website builder. The platform's own account-recovery support is the faster route.
• You need a certified vendor or a language other than English. RAITHub is not SOC 2 or ISO 27001 certified and works in English.

If none of those apply, pick Code Rescue on the contact form and book the free 15-minute audit. Bring your filled-in access table, the contract and the three problems costing you most.

Last reviewed: 28 September 2026

Frequently asked questions

My developer disappeared with my code. What is the first thing to do?

Send one polite, written request for access with a clear deadline, then list every account the product depends on. Secure the domain registrar first, because whoever controls the domain can reset passwords on almost every other account.

A freelancer ghosted me mid-project. Do I own the code?

It depends on your contract and your jurisdiction, so check the IP clause with a lawyer. Paying for code does not automatically mean you own it; a written assignment, ideally a present assignment, is what removes the doubt.

Can I recover a domain registered in the developer's name?

Sometimes, but it is harder. For generic domains, ICANN's Transfer Policy gives the registered name holder the final say over transfers, so if the developer is the registrant you will usually need their cooperation or a legal route.

Should I revoke the developer's access straight away?

Not before you have your own admin access to each account. If deploys or database connections depend on their credentials, revoking first can take production down. Secure your access, inventory the secrets, then revoke and rotate.

What if my agency stopped responding but still hosts the app?

Ask in writing for a transfer of the hosting project, repository and database to accounts you own, and take a database backup as soon as you can. If they will not transfer, you may need to redeploy into a new account once you control the domain and the code.

Should I rewrite the app with a new developer?

Usually not as a first step. Run a diagnostic to find what is actually broken, keep the data model and working code, and replace only the modules that keep costing you. Rewrite when the code is a prototype nothing depends on or the platform is at end of life.

How can I stop this happening again?

Keep every account in company hands with two admins, keep the code in your own repository from the first commit, and put a present-assignment IP clause and a handover obligation in the contract before work starts.