Your software developer has disappeared. Now what?
It happens far more often than anyone admits. The freelancer who built your system stops answering emails. The one-man agency retires, or burns out, or takes a job. The company folds and the phone number dies with it. Meanwhile the system they built is still running your business, and you have just realised that nobody on your payroll knows how.
We take over systems in exactly this state regularly, so here is the guidance we give on the first phone call, written down. The short version: your system is almost certainly recoverable, the situation is rarely as fragile as it feels, and the expensive mistakes are the ones made in a panic during week one.
First, find out what you actually control
Before deciding anything, spend an hour establishing where the pieces live. There are six that matter: the domain name, the DNS, the hosting account, the source code, the database, and the third-party services the system leans on, such as the payment provider and whatever sends its emails. For each one, the question is the same. Is the account in your name, or theirs?
Your paper trail answers most of this. Invoices show who has been paying for hosting and the domain. Old emails contain login details, welcome messages from providers, and renewal notices. Businesses in this position usually discover they control more than they feared, and the gaps they find are exactly the list to hand to whoever takes over.
The renewals are the real deadline
Here is the part that makes this urgent even when the system runs perfectly. Domains, certificates and hosting renew on cards, and if any of them renew on the developer's card, they are now renewing on the card of someone who has stopped answering. Nothing visible changes until the day it does, and a lapsed domain takes your email down with your website. Check the domain's expiry date today. It is public information, and it is the difference between a planned handover and a genuine emergency with a countdown attached.
What can be recovered without them
More than most people expect. For a typical web system, a complete working copy of the application lives on the server it runs from, because that is what running means. If the hosting account is yours, or can be transferred to you, then the code, the database and the uploaded files are all recoverable from there, with or without the original developer's repository. It is how we start most takeovers of abandoned systems: the code comes off the server, goes into proper source control, and the system has a future again.
The developer being unreachable is an inconvenience, not a wall. What they carry that cannot be recovered is the knowledge in their head, and while that knowledge was valuable, the code is the one description of the system that cannot be out of date. Years of pricing rules and hard-won fixes are in there, waiting to be read by someone who reads code for a living.
The first week, in order
One: resist the urge to announce a rebuild. A system that runs today is an asset, and the decision about its future goes better in week four than week one.
Two: secure the accounts you legitimately control. Change the passwords on your own hosting, domain and third-party accounts, and turn on two-factor authentication while you are in there. Not out of suspicion, but because access nobody is watching is access nobody is protecting.
Three: get a backup that exists somewhere other than the server itself, and have someone confirm it can actually be restored. If the server is the only place your data lives, that is the single riskiest fact in the whole situation, and it is fixable in a day.
Four: write to the developer once, politely and specifically. Ask for the code, the credentials, and anything they hold in their own accounts. Most cases resolve here, because most disappearances are burnout or life getting in the way rather than anything worse, and a clear request with no blame attached gets a better response than a legal letter.
Five: with the system backed up and access secured, decide calmly. That is the point to bring in help, because now a takeover can be assessed and priced rather than firefought.
Who owns the code?
The question everyone asks, so here is the practical answer. What you own depends on your contract, and where real money turns on it, that is a question for a solicitor, not a blog post. But in practice the argument matters less than people fear. The system running on your infrastructure, holding your data, is something a new team can legitimately maintain and develop for you while any ownership questions get resolved. We have never seen the paperwork question stop a takeover. The work carries on while the letters cross.
What putting it right costs
The takeover itself, getting the code into source control, the credentials inventoried, the backups proven, monitoring on and deployments made safe, runs £4,000 to £8,000 where access is reasonable, and up to £16,000 where things have to be recovered the hard way. After that, support from £250 a month keeps it patched and watched. The full arithmetic, including what modernising it afterwards costs, is in what legacy modernisation costs, and the legacy modernisation calculator will price your particular situation in about two minutes.
Common questions
Can another company take over without the original developer's help?
Yes, and it is routine work for firms that specialise in it. The essentials are access to the running system and its hosting, and ideally the code, which can usually be recovered from the server itself. Cooperation makes things faster but is not required.
The developer has the only copy of the code. What do we do?
Establish what runs on your hosting first, because for most web systems a working copy of the application lives on the server, and if the hosting account is yours that copy is recoverable regardless of who holds the repository. A polite, specific written request resolves most cases; where it does not, the server copy is usually enough to carry on.
The system still runs fine. How urgent is this really?
More urgent than it feels, because of renewals. Domains, certificates and hosting often renew on the developer's own card, and each lapses silently until the day the system vanishes. Check the domain expiry first. After that, urgency depends on whether the stack still receives security patches.
Do we have to rebuild from scratch?
Almost never, and deciding to rebuild in week one is the most expensive mistake available in this situation. Secure access, prove a backup, recover the code, then decide calmly. Most systems in this position are taken over and carried on, not replaced.