My website's developer is gone. What do I do now?

This happens in a few different ways. A developer passes away. A development agency closes down. Someone simply stops replying to emails. Or you take over a business and find a website that nobody left any instructions for. The cause is different each time, but the immediate problem is usually the same: your site or app is still running, and nobody has clear control over it.

This page walks through the practical steps in order. What to check first whatever the cause, what changes depending on your situation, and where things tend to get properly stuck.

You are not in an unusual position. A big share of small business websites are built and looked after by one freelancer or a very small agency, sometimes with nobody else ever having touched the code. When that person or company disappears there is often no documented way back in. It is rarely anyone's fault. It is a gap nobody planned for.

Step one: stabilise what's running

Before you think about the code, think about what keeps the site online at all. None of this needs any technical knowledge, and it is worth doing before anything else.

Start by running a lookup on your own domain. A free tool like MXToolbox will show you who your domain is registered with, when it is due to expire, where its DNS points and how your email is routed, all in one report. Save a copy. It is exactly the summary a developer taking this on will ask for first, and having it ready saves a round of questions.

From that report, look for:

• The domain registrar, and how close the renewal date is.
• Your hosting provider, meaning where the site is actually served from. Sometimes this is the same company as the registrar, often it isn't.
• Your email setup (the MX records). If your business email runs on the same domain, it depends on the same infrastructure. This gets missed constantly. People focus on "the website" and forget that customer emails can stop arriving on the day a domain lapses.
• SSL certificate status. If it doesn't renew automatically, visitors will eventually see a security warning rather than your site.

Once you know who the suppliers are, contact each one directly and explain what has happened. Registrars and hosts have dealt with this before, even if you haven't.

Step two: what changes depending on your situation

The developer has died

This is the hardest version to deal with, and often the slowest to resolve. Suppliers will generally want some proof that you are entitled to act on the account holder's behalf before they change anything. What counts as enough proof varies a lot from company to company, so ask each one what they need rather than assuming.

In our experience, formal legal involvement is needed less often than people expect. It matters more when the domain or hosting is registered in the developer's personal name rather than a business name, or when there is a dispute over who is entitled to what. Outside of that, it is usually a conversation with a supplier's support team rather than a legal process.

How you phrase that conversation matters more than you would think. Suppliers deal with account takeover fraud all the time, and a stranger asking to take control of an account can easily be flagged as suspicious even when the request is completely genuine. Knowing what a particular registrar or host needs to hear, and what tends to trigger a fraud review instead of a helpful answer, is something an experienced developer can do for you.

The development agency has gone out of business

This is usually more straightforward, because there is a company to deal with rather than an individual's affairs, and contracts and ownership are more likely to be written down somewhere, even if nobody can currently find them.

Check whether you have a contract or terms of service on file. It may say what happens to the code and hosting if the agency stops trading. If the agency has formally entered insolvency, the person appointed to handle it may hold, or know where to find, things like code repositories and client records. Contacting them is often the quickest route.

The developer has gone quiet

Sometimes nothing dramatic has happened. Someone just stops replying, and you can't tell whether to wait or move on. There is no fixed rule for how long to wait, but if a hosting or domain renewal is approaching and you can't confirm anyone is looking after the accounts, it is reasonable to start securing access at the same time rather than waiting indefinitely. Many registrars and hosts can add you as an extra contact on the account, or start a transfer, without the original developer's involvement, as long as you can show you are the legitimate business owner.

You've inherited a website and don't know what it is

This covers taking over a business, a family member's project, or a part of the organisation nobody previously looked after. The challenge here is less about access and more about discovery: working out what it is built on, where it lives and whether anyone is maintaining it at all. The lookup from step one is where to start, even with no other context.

Step three: find the code

What finding the code means depends on how the site was built. This is the point where it is worth getting a developer involved, even briefly, just to tell you what you are looking at.

If the site runs on something like PHP or WordPress, hosting access usually is code access. The files on the server are the same readable source the developer wrote, so once someone can log in to the hosting account there is normally nothing further to find.

If it runs on something compiled, such as .NET or Java, the server holds a built, working copy of the site but not the original source. It runs perfectly well, but a developer can't read or edit it directly. Getting back to editable code means finding the original project files, which are usually in one of two places:

• A code repository such as GitHub, GitLab or Bitbucket, if the developer used one and you can get access to it.
• A backup or handover kept by the developer or their business, separate from the live server.

Sometimes the answer turns up somewhere you wouldn't expect. We took on a project for a charity supporting people with terminal illness, running on a .NET application, after their previous developer became unavailable. Because .NET compiles into a form that isn't readable, we expected to be picking apart the running application from scratch, which is slow and produces much messier results than working from real source. Instead we found the developer had put the actual source code in a public GitHub repository, apparently just as a convenient place to keep it. It saved the charity a costly rebuild. That isn't a likely outcome, but it is a good reason to check properly before assuming the worst.

When the code can't be recovered

We would rather be upfront about this than pretend every situation has a fix, because it doesn't.

Sometimes there is no source to find: a compiled application with no repository or backup anywhere. Sometimes the only copy of everything was on a personal device that nobody can unlock. Either way, the original code can end up genuinely gone.

If that happens, the realistic options are usually these:

• Rebuild the front end from the live site. Whatever a browser displays is visible to anyone, so a developer can recreate the look and structure fairly reliably without the original files.
• Rebuild the underlying functionality from scratch, working from how the site behaves today.
• Decide what is actually worth reconstructing, and accept that the rest is lost.

It isn't the outcome anyone wants, but knowing it is possible early on is far easier than finding out halfway through.

How we can help

We take on websites and web applications that someone else built and can no longer support. Most of our work in this area starts the same way, with a feasibility review, and it is designed for exactly the situation where nobody knows what is out there yet.

What the feasibility review involves

You give us whatever access and information you have. That might be a hosting login, a domain registrar account, a repository link, a folder of old invoices, or just the name of the site. We bring a block of our time and use it to:

1. Work out what the site is built on and where every piece of it lives, including the domain, hosting, email and any third party services it relies on.
2. Get hold of the code, or establish honestly that we can't.
3. Set up a working development environment, so the site or app runs somewhere we can safely look at it.
4. Go through what we find against the list of things you need done, whether that is a bug fix, a security update, a new feature or simply keeping the lights on.

At the end you get a plain English summary of what is there, what condition it is in, what the risks are, and what your realistic options are, including the ones that cost money. You can take that to us for the next stage, or to anyone else.

The time is billed upfront, and we can't promise specific deliverables from it. Until we are inside the project, nobody can say whether it will be a quick fix or a rebuild. We would rather tell you that now than have you find out later.

Some examples of where we've helped

The code was somewhere nobody thought to look. The charity above is the best example. A compiled .NET application, a developer who was no longer available, and a rebuild that looked unavoidable. Looking properly turned up the source in a public repository, and the project went on from there instead of starting again.

The previous developer's estate couldn't release their files. Sometimes a family or estate is reluctant to hand over a laptop or accounts, understandably, because the same devices hold other clients' confidential work. In those cases we work with what can be reached on the live infrastructure, and rebuild what has to be rebuilt, rather than waiting on something that may never arrive.

The domain was in the developer's personal name. This is one of the most common problems we see. We know how to approach registrars so the request is taken seriously and not mistaken for an attempt to hijack an account, which saves a lot of time and stress at an already difficult point.

A site on a platform we hadn't built on before. Taking over somebody else's work often means meeting technologies and setups we haven't used. That is part of why we enjoy it, and part of why we start with a review rather than quoting blind.

What we won't do

We won't promise to recover something that can't be recovered. We won't pretend legal questions about ownership and inheritance are ours to answer. Where those come up we will say so, and point you to someone who can help. And we won't push you into a rebuild when a repair would do.

If you are not sure whether your situation is something we can help with, get in touch and describe it. A short conversation usually makes it clear.

Get in touch about a feasibility review →

---

Frequently asked questions

How do I find out who hosts our website if we don't know? A free WHOIS and DNS lookup tool such as MXToolbox will usually show your registrar and where your DNS points, which is generally enough to identify your hosting provider too.

Will our website go offline straight away? Not necessarily. A site normally keeps running for as long as the domain and hosting stay paid for and nothing breaks. The risk is the quiet deadlines: a domain renewal, a hosting payment on someone else's card, or an expiring certificate. That is why securing those comes first.

What if our domain is about to expire? Contact the registrar straight away, even before everything else is sorted. Explain the situation and ask what options they have. Most have some kind of grace period, though it varies by company and domain type.

Will a hosting company or registrar hand over access if I explain what happened? Not usually on request alone. Most will want some proof that you are entitled to act on the account holder's behalf, and what counts varies from company to company. Ask what they specifically require.

Do we need a solicitor to sort this out? Often not, in our experience. Most of it is a conversation with the suppliers involved rather than a legal process. Legal advice becomes more likely to be useful if the domain or hosting is in an individual's personal name, or if there is a dispute over who is entitled to what.

What if our development agency has gone into liquidation? Whoever has been appointed to deal with the company may hold, or know the location of, its remaining assets, including code repositories. It is usually the best place to start.

Do we need the original code to move forward? It makes things much easier, but it isn't always essential. For some kinds of site the code sits on the server and is easy to get. For others it has to be found elsewhere. If it can't be found, the site can often still be rebuilt using the live version as a guide.

Can you work on a site if you didn't build it? Yes, that is most of what this kind of work is. We regularly pick up projects built by other people, on technologies and setups we may not have seen before. The feasibility review exists to find out what we are dealing with before anyone commits to anything bigger.

How long does the feasibility review take, and what does it cost? It depends on the size and complexity of the site and how much access you can give us. We bill a block of time upfront, and we can usually give you an idea of the size of block once we have heard what you have. Get in touch and we will talk it through.

Is this different for a web application than for a normal website? Often, yes. A web application usually has a database, user accounts, scheduled jobs and connections to other services, all of which need to be found and understood. It tends to take longer to review than a brochure site, but the approach is the same.

How do we stop this happening again? Make sure the business, not an individual, owns the domain and hosting accounts. Keep a copy of the code in a repository that your organisation controls. Ask your developer to keep brief notes on how the site is built and where things live. And keep a short list of who to contact at each supplier. None of it takes long, and it would have saved nearly every client we have helped in this situation.