What to do when your software developer disappears
9 min read
Key takeaways
Your developer has stopped replying. Here is what to do first, what has a deadline on it, and how to work out how much trouble you are actually in. Most of it costs nothing.
Somebody stops replying. That is usually how it starts, and it rarely announces itself.
An email goes unanswered for a few days, which happens to everybody. Then a week. Then the phone goes to voicemail, and the voicemail is full. By the time most people search for what to do about it, they have been waiting a month and have started to feel foolish for having waited that long.
They should not. A month is a reasonable amount of time to give somebody the benefit of the doubt, particularly somebody who has been reliable up to that point. Almost everybody we speak to in this situation says some version of "I should have chased sooner", and almost none of them should have.
This article is what to do from here. Most of it costs nothing, and the first part of it you can do this afternoon.
Start by assuming it is recoverable, because it usually is
We take on systems whose original developer is gone most weeks of the year, and the honest summary after thirty years of it is that the software is almost always fine. It is sitting on a server, running, doing its job. Nobody has taken it away.
What has gone is the knowledge and the access, and those are rebuildable. Slower than having them, and it costs something, but rebuildable.
The genuinely bad cases are rare and they are specific: the domain lapses and somebody else registers it, or there is no copy of the code anywhere except a machine nobody can reach. Both of those are avoidable if you act in the next few weeks, which is the real reason not to leave this sitting.
The first hour: collect, do not change
The instinct is to start fixing. Resist it for one hour and gather instead, because everything you do later is easier with this in front of you.
- Write down every account the system touches. Domain registrar, DNS, hosting or cloud, code repository, payment provider, email sender, analytics, app store listings. You are not trying to get into them yet. You are making the list.
- Take your own backup of anything you can already reach. If you can log into the hosting, download the files and export the database. If you can reach the repository, clone it. A copy you hold yourself is the only one you can be certain of.
- Find the paperwork. The contract or the proposal, the last few invoices, and any email where they described what they had built. Invoices matter more than people expect: they often name the hosting company or the services being paid for.
- Gather the correspondence into one place. If you ever need a registrar or a hosting company to believe the system is yours, that trail is the evidence.
- Check when your domain expires. This is the one with a clock on it, and it is free to check. More on it below.
The one thing that has a deadline
Everything else on this list can wait a fortnight without getting worse. Your domain cannot.
If the domain was registered in your developer's account, it is renewing on their card. If that card stops working, or the renewal notices go to an inbox nobody is reading, the domain expires. When a domain expires your website goes down and your email stops arriving, both at the same time, and the first you know of it is usually a customer mentioning it.
There is normally a grace period after expiry, often around thirty days, in which the original registrant can still renew. After that it can be released for anybody to register, and at that point getting it back stops being a process and becomes a negotiation with whoever now holds it.
You can check the expiry date for nothing. Search for a WHOIS lookup, enter your domain, and read the expiry field. Do that today, write the date in your diary, and you have converted the one genuine emergency in this situation into a known deadline.
What not to do
Do not let anybody tidy up. The most expensive instinct in software is the urge to clean. A scheduled job with a meaningless name, a table that looks like a duplicate, a script on a server everybody forgot about: in a system nobody currently understands, assume all of it is doing something until somebody can explain what.
Do not switch anything off to see what breaks. You will find out, and it will be in front of a customer.
Do not change passwords on accounts you still depend on until you are certain you can get back in. Locking yourself out of a working system is a self-inflicted version of the problem you are already trying to solve.
Do not start a rebuild yet. Somebody will suggest it, often within the first week, and it is occasionally the right answer. It is not something to decide before anybody has read what you already have.
Working out how bad it actually is
Three questions decide how much work this is, and you can answer them without a developer.
Do you have the code? Not "does it exist somewhere", but is there a copy you can reach.
Can the accounts be recovered? Are they in your name, in your company's name, or in theirs.
Is the system running? A system that is still up buys you time. A system that is down does not.
Those three produce roughly four situations. Code and accounts in your name, still running: an inconvenience, and somebody new can pick it up in days. Accounts yours but no code: recoverable, because the code is usually still on the server and can be retrieved from there. Code but no accounts: a paperwork job with the registrar and the hosting company, tedious rather than difficult. Neither, and nobody can get in anywhere: this is the one worth moving on quickly, and it is still not hopeless, because hosting companies and registrars have processes for exactly this.
Getting back into the accounts, in the right order
Do these one at a time and in this order, because the early ones are the ones with consequences.
Domain and DNS first. Whoever controls DNS controls where your website and your email go. Every registrar has a process for transferring a domain when the named contact is unreachable, and it is usually a form plus evidence that the domain belongs to your business: company details, invoices, the correspondence you gathered earlier. Phone them. This is a common request and they will have done it before.
Hosting second. Same approach. If you are paying the bill, or your company name is on the account, you have a strong case. If your developer was paying, find the invoices and work out which company it is.
The code third. If you cannot reach the repository, the running code is on the server, and once you have hosting access you can download it. It will be missing its history, which is a loss but not a blocker.
Everything else last. Payment provider, mail sender, analytics, app store listings. These matter, but none of them takes your business off the air this week.
If something has happened to them
It is worth saying plainly, because it comes up more than people expect: sometimes the reason somebody has stopped replying is that they are seriously ill, or they have died, or their business has collapsed around them.
If you have any reason to think that, the decent thing and the practical thing point the same way. A short, kind message to a family member or a former colleague gets access sorted more often than a solicitor's letter does, and you will not spend the next year wishing you had handled it differently.
If the company has gone into administration, the administrator is the route. They are obliged to deal with creditors and they can release your data and your code. Write to them, describe what is yours, and be specific.
The legal position, briefly
We are developers, not solicitors, so treat this as the thing to ask about rather than as the advice itself.
Two points are worth knowing before you spend money on legal help. First, if a contractor or an agency wrote your software, the default position in the UK is that they hold the copyright and you have a licence to use it for the purpose it was commissioned for. Paying the invoice does not transfer ownership. Only a written assignment does, and most small contracts never mention it. That does not stop you running your system or having somebody else maintain it, which is what matters here.
Second, if you have genuinely been defrauded, that is Action Fraud, trading standards or a solicitor, and it is a separate matter from getting your software working again. We will not pretend to be an alternative to any of them. We cannot recover money that has been paid, and anybody who implies they can is worth being careful with.
What it costs to get somebody else in
The honest answer is that the reading comes first and it is the cheap part.
A system that has frightened a business for months usually takes days to map, not weeks, and what comes out of it is a written description of what you have, what state it is in, and what it would cost to carry on. Once that exists, this is a job like any other and it can be priced.
The thing to be wary of is anybody who quotes a rebuild before they have read what you have. Rebuilding is sometimes right. It cannot be known to be right in advance.
What we do
We should be straight about our own position, since this article has spent a page telling you what to ask of other people.
We read the system first and tell you what we find in writing, including the case for not spending money with us. If starting again would genuinely be cheaper than carrying on, that is what the document will say. Somebody who has already lost money once should not have to take our word for the second opinion as well.
If you go ahead, every account is in your name from the first day: the repository, the hosting, the domain, everything the system runs on. On the code itself we keep the copyright, and you hold a perpetual licence to use it for your project, change it, and have anybody at all change it, with us or without us. It does not lapse if you stop working with us, which is rather the point: if we disappeared tomorrow you could carry the project on with somebody else. What you cannot do is sell that code on, or use it as the basis of a different product, without our agreement. You will never be in the position this article describes because of us.
Nothing we open is going to be something we have not already seen.
If you would rather start smaller
If you are not ready to speak to anybody, there is a shorter route. Our project healthcheck is twelve questions and takes about two minutes, it does not ask for an email address, and most of what it recommends costs nothing and does not involve us.
That is the sensible first step for most people in this position, and it is deliberately the one that asks you for the least.
Matt Houldsworth
Matt has spent thirty years building software that has to work, from systems handling a hundred million database transactions an hour to ecommerce platforms turning over millions of pounds a month. He founded Software Delivered to price development honestly and to rescue the projects other people walked away from.