Recovering your source code (and access) from a developer who vanished

You paid for an app, a website or an internal tool. It works, it's online, real people use it. But the moment you try to touch it, you discover something that makes your stomach drop: you control none of it. The code lives on a GitHub that isn't yours. The domain is registered under someone else's name. The server is managed by a person who stopped replying. The product is yours on paper only.

If you're here, you've probably already been through the developer going silent. Now the problem is different and more concrete: physically taking back ownership of your product. This article is the exact sequence I walk founders through when they call me in a panic because «I'm holding nothing».

First rule: the code is not the most urgent piece

The instinct is to chase the source code. Wrong. In most cases the code is recoverable or rebuildable. What can do real, irreversible damage within 48 hours is losing the domain and access to the services that move the money (payments, transactional email, the accounts your customers are registered on). Those come first.

The correct priority order is: domain and DNS → payments and customer data → hosting and server → database → source code. Let's see why and how.

Step 1 — Inventory what you do NOT control

Open a sheet and mark, for each item, whether access is in your name, shared or the developer's only:

• Domain— which registrar (Aruba, Namecheap, GoDaddy, Cloudflare…) and who it's registered to.
• DNS — who controls the records (often separate from the registrar, e.g. Cloudflare).
• Hosting / server — where the product runs (AWS, Vercel, Hetzner, a VPS, shared hosting).
• Code repository — GitHub, GitLab, Bitbucket, and on which account/organization.
• Database — where the real data lives (managed, self-hosted, inside the server).
• Payments — Stripe, PayPal: whose account collects the money.
• Transactional email — SendGrid, Mailgun, Postmark: it sends confirmations and password resets to your customers.
• Third-party accounts — Google Cloud, app stores (Apple/Google Play), Firebase, maps services, etc.

This sheet is your map. Everything that is «the developer's only» is a risk point. Everything «in your name» is already safe.

Step 2 — The uncomfortable truth about «your» code

I have to be honest, because no one tells you this: the code may not legally be yours the way you assume. In Italy (and in much of Europe), without a contract that explicitly assigns intellectual property (an IP assignment clause), whoever wrote the software keeps part of the rights — even if you paid for it.

This is not legal advice and every case is different — but before you go on the attack, dig out the contract, or even just the emails and quotes: you need them both to understand what you can demand and in case it ends up with a lawyer. In practice the «technical» route (reclaiming the access that is effectively yours) is almost always faster than the legal one. But knowing where you stand changes the tone of the last message you send the developer.

Step 3 — Recover domain and DNS first

The domain is the piece that, if you lose it, takes everything down with it: site, business email, links in your materials, rankings. It's also what an unhappy developer can most easily hold hostage.

• If it's in your name — log into the registrar, change the password, enable 2FA, and remove the developer from delegated users. Done.
• If you don't have access— almost every registrar has a recovery process based on the email or the registrant's details. If the registrant is you (even just as a person/company in the WHOIS data), you can reclaim it by opening a ticket and showing an ID.
• To move it elsewhere you need the authorization code(authcode / EPP code). If you can't get it, a transfer via the new registrar's support is still possible, just slower.

Step 4 — Secure payments and customer data

If you collect money through a Stripe/PayPal account that isn't registered to your company, you have a double problem: money and data. Immediately check whose name the receiving account is under and which bank account the payouts go to. The same goes for transactional email: if it disappears, your customers stop getting confirmations and password resets — and you only find out when they complain.

Wherever you can, export now: the customer list, the orders, the invoices. They are yours, and an export protects you no matter what happens to the access.

Step 5 — Hosting, server and database

The goal here is twofold: get access and make a full backup before anyone shuts anything down.

• Cloud provider(AWS, Vercel, GCP) — if the account is yours, rotate credentials and revoke the developer's API keys/access tokens. If it's theirs, the only way is to get access or rebuild the infrastructure elsewhere from the backup.
• Server / VPS — if you have access, take a full disk snapshot. It's your insurance: the running code and the configuration usually live there.
• Database — take a full dumpand download it locally. Data is the part you can't rebuild: code can be rewritten, three years of orders can't.

Step 6 — The source code, finally

Now that the painful things are safe, the code. Three scenarios:

• You have repository access — perfect. Transfer ownership of the repo to your organization (GitHub/GitLab do this in a few clicks) or clone it locally and push it to an account of yours. Then remove the developer from collaborators.
• No repo, but you have the server — the running code is almost always there. From a server snapshot you recover the source (or at least the build) and restart.
• Neither repo nor server — the worst case, but not the end. Go to the next step.

If you're holding NOTHING

It happens: product online, zero access. There's a way here too. The product in production isa source of information: the frontend is downloadable (it's what the browser already receives), the APIs can be mapped by watching how the site calls them, the visible data can be exported. You won't recover the original source, but you rebuild enough not to start from a blank page — often with a cleaner result than before.

The real question at that point isn't «how do I recover the exact old code» but «is it worth recovering or rebuilding?». Often a half-finished product left by a vanished developer is more expensive to understand and fix than to rebuild properly. That's a decision you make by looking at the code, not by guessing.

How to never end up here again

Once you're back in control, lock it down so you never again depend on one person's goodwill:

• Every account in your company's name. Domain, hosting, repo, payments, email: you're the registrant, always. The developer is invited, not the owner.
• The repository on your organization from day one. Whoever works on it has collaborator access.
• An IP assignment clause in the contract.One line stating the code produced is yours. Without it, you're back to square one.
• An automated backupof code and database that doesn't pass through the developer's hands.

Where I come in

When a founder calls me in this situation, the first thing we do together is exactly the inventory above: in half a day you know what's genuinely at risk and what's already safe. From there I recover the technical access, secure data and infrastructure, and tell you honestly whether the existing software is worth keeping or not. This isn't a job for «another freelancer»: it takes someone who's seen enough systems to know where to look.

If you're in this right now, the worst thing you can do is wait and hope the developer resurfaces. Every day that passes is one more risk on your domain, data and access.

Frequently asked questions