How to Get Your Code, Repo and Domain Back From a Developer Who Stopped Replying

The last reply came three days ago. Before that, answers arrived within hours. Now there is nothing: no response on email, none on chat, and the invoice you paid a fortnight ago has bought you silence. Somewhere behind that silence sit your application, your customer data, and quite possibly your domain name.

This is the order of operations we use when someone arrives in exactly that state. Two things before the list.

First, we are engineers, not lawyers. Everything below is about finding and securing what is already yours, using the recovery processes that registrars, hosting companies and code platforms publish for this purpose. The moment the real question becomes "who owns this code" or "can I reverse that payment", you need a lawyer in your own jurisdiction, not a blog post. That line is marked clearly further down.

Second, resist the urge to open with a confrontation. An angry message gains you nothing and costs you something real: it tells a person who still holds keys that the relationship is over, before you know which keys you hold yourself. Find that out first.

Step 1: Inventory every asset, and note who owns the account

Open a spreadsheet. One row per asset, three columns: what it is, where it lives, and whose email address is on the account. Work through this list and do not skip the boring half.

• The domain name, and separately, wherever DNS is actually managed. They are often two different companies.
• Hosting or cloud: the web host, the serverless platform, the virtual machines, the container registry.
• The database, including any managed database that sits apart from the app.
• The code: GitHub, GitLab, Bitbucket, or a zip file on somebody's laptop.
• Email: the service that sends your transactional mail, and the service that runs your company mailboxes.
• Money: payment processing, subscriptions, invoicing.
• The app stores, if you have a mobile app. These are the slowest of all to recover, so find out early.
• Everything with an API key: file storage, maps, SMS, authentication providers, error tracking, analytics, the content system.

The column that matters is the third one. Every asset falls into one of three states: yours (your email is the owner, you can reset the password today), theirs (their account, their email, you have no direct route in), or unknown. The unknowns are the work.

Step 2: Mine your own inbox before you ask anyone anything

This is the highest-yield fifteen minutes in the whole process, and almost nobody does it first.

Every service on earth sends a welcome email, a receipt, or a password reset. Search your mail, including spam and any shared company mailbox, for terms like "welcome to", "verify your email", "your receipt", "invoice", "subscription", "trial ends" and "password reset". Search your card and bank statements for recurring charges you cannot place.

You will find accounts you forgot you own, which converts "theirs" into "yours" for free. You will also find the shape of the system: the receipts tell you which platforms are actually in use, which is the closest thing to an architecture diagram you are going to get today.

Step 3: Secure the domain first, before anything else

The domain is the most valuable and most fragile thing you own. Lose it and you lose your website, your company email, your password resets, and your ability to prove you are you. Everything else can be rebuilt. This can be held hostage.

Look up your domain in any public WHOIS lookup. That tells you the registrar even when it hides the contact details. Then:

• If the registrar account is yours, log in today. Turn on two-factor authentication, confirm the registrant email is one you control, check the expiry date, and enable auto-renew. A domain that quietly expires during a dispute is a disaster that nobody chose.
• If the account is theirs, do not panic and do not start a transfer war. Registrars have documented processes for changing a registrant and for disputed ownership, and they are the only route that works. Contact the registrar's support directly, explain the situation plainly, and ask what evidence they require. Have your invoices and your correspondence ready.
• If DNS is managed somewhere you cannot reach, note it. It means someone else can point your name anywhere they like, which is worth knowing before you decide how to handle the conversation.

Step 4: Take whatever copy of the code you can reach

You may have more of the code than you think, and none of these routes need the developer's cooperation.

• A repository you are a member of. Clone it now, to your own machine, and do not rely on it staying there. If the repository sits inside an organisation you own, you control the membership; if it sits in their personal account, you do not, and no amount of asking the platform will change that.
• A running server. If you can log into the host, the deployed application is on it. For most stacks that is the source, or close enough to it to work with.
• A build or deploy platform. Deployment histories keep artefacts, and some keep the source they were built from.
• Anything they ever sent you. Zip files in old emails, screen recordings, a staging link, even the documentation they wrote in month one. It all counts as evidence of what existed.

Copy everything you find into storage you own, today, and stop touching the originals.

Step 5: Back up the data before you do anything else clever

If you can reach the database at all, export it now, and store the export somewhere unrelated to the system it came from. Then do it again tomorrow.

Data is the one asset that cannot be recreated. Code can be rewritten, painfully. A design can be redrawn. Your customers' records exist in exactly one place, and if that place is a database inside an account you do not control, on a plan somebody else is paying for, you are one lapsed card away from losing the business rather than the project.

Step 6: Close the money doors you control

Two separate jobs, and only one of them is urgent.

The urgent one is anything that can spend your money: cloud accounts on your card, paid services on auto-renew, subscriptions you no longer benefit from. Work out what will break before you cancel anything, because cutting off a service the live application depends on is a self-inflicted outage.

The one to slow down on is payments to the developer. Stopping a scheduled payment is straightforward. A chargeback or a dispute is not, and it has consequences for what happens next, including whether you get any cooperation at all. That decision belongs in the conversation with your lawyer, in step 8, not in this step.

Step 7: Build the record while it is fresh

Not for drama. For whoever picks this up next, which will be a lawyer, an accountant, a payment provider, or the developer who takes over.

In one document, write the dates: when work started, what was promised, what was delivered, what you paid and when, and when the replies stopped. Export the message threads rather than screenshotting a few of them. Save the contract or, if there is no contract, the emails and messages where the work was agreed.

This takes an hour and it never gets easier than it is today, while you can still remember which week was which.

Step 8: Where this stops being a technical problem

Everything above is yours to do without permission from anyone. The following questions are not, and they are the ones where guessing costs the most:

• Who owns the code that was written for you, and does paying for it mean owning it?
• What can you require them to hand over, and how?
• Can you recover money for work that was not delivered?
• What are you allowed to do with a system you can access but do not own?

The honest answer is that these depend on your contract and your jurisdiction, and that anyone who answers them confidently on a marketing page is guessing on your behalf. Get a lawyer where you are. Bring them the document from step 7 and the spreadsheet from step 1, and the conversation will take a fraction of the time.

Do not hire the next developer yet

The most expensive mistake in this whole situation is not the first developer. It is the second one, hired in a hurry, in the dark, to fix something nobody has read.

You cannot brief anyone properly until you know what you hold, what state it is in, and what it would take to move forward. Hire before that and you are asking a stranger to quote on an unknown, which means either a padded price or a cheap one that gets revised upward the moment they open the code. That is how the same story happens twice.

Reading the codebase and telling you where you stand is the thing we productised as a free rescue assessment: a written verdict on what you actually have, a map of where the risk sits, and a plan for what to do next, delivered in 48 to 72 hours and yours to keep whether or not you ever hire us. If you want to hand it to a different developer instead, that works too. That is the point of it being written down.

Either way, the sequence is the same one this post has been circling. Secure, then understand, then decide. The silence at the other end of the thread is genuinely awful, and it is also the least urgent thing on the list.