When a developer goes quiet, the problem is rarely the code. It is that access to things you own is held in accounts you do not control. Domain, DNS, hosting, admin and repository, in that order, and four of the five can be recovered through billing rather than goodwill.
If you are reading this because somebody has gone quiet on you, start here: in almost every case I have seen, nothing is actually lost. It feels like it is. It usually is not.
I get this call a few times a year, and it always arrives sounding like a catastrophe. It rarely is one. What has almost always happened is that access to things you own is sitting inside an account you do not control. That is recoverable, it is mostly paperwork rather than engineering, and you can do most of it today without hiring anybody. Here is the order I would do it in.
The cost is not the site breaking
The cost of a developer going quiet is rarely the site breaking. It is that you cannot change anything, so the business stops being able to move: no new page before the campaign, no price update, no fix for the form that stopped working.
Worse, the clock is running on things you cannot see. A domain renews or it does not. A certificate expires or it does not. Those are dated events that happen whether anyone is paying attention, and the first sign of trouble is usually the site simply going dark on a Tuesday morning.
So the priority is not “get the site rebuilt”. It is “get control of the five things that expire”, and then decide calmly.
The five things you need to control
Work down this list in order. The top one matters most and is the one people most often do not have.
| What | Why it is first | How to check |
|---|---|---|
| Domain registration | Everything else is replaceable. This is not. | Look up your domain on a public WHOIS service and see who the registrant is |
| DNS control | Decides where the domain points, including email | The nameservers show in the same WHOIS record |
| Hosting account | Where the site and database actually live | Search your card statements for a recurring charge |
| Site administrator login | Lets you edit content and add a new admin | Try the password reset on your own email address |
| The code and its history | Determines whether the next person starts fresh or continues | Ask where the repository is, and who owns that account |
Notice that four of the five can be recovered through billing and identity rather than goodwill. If your name is on the payment method or the registration, providers have a process for this. It is not fast, and it is not friendly, but it exists and it does not require the missing person to answer anything.
Do these today
Find out who owns the domain. Public WHOIS will tell you the registrar even when the details are private. If the registrant is your business, you can recover the account through the registrar. If it is the developer or their company, that is the single most urgent conversation to have, and it is worth being generous to resolve it quickly.
Get your own administrator account. If you can still reach the site’s login, request a password reset to an email address you control. If you already have an admin account, make a second one on a company address and store the credentials somewhere central. Do not skip this because you currently have access; the point is to hold it independently of any one person.
Find the recurring charges. Hosting, domain, email, and any paid services all leave a trail on a card statement. That trail tells you which companies hold your things, which is exactly what you need to start recovery.
Take a copy of everything, now. Before changing passwords, before anyone gets nervous, take a full backup of the site and database and put it somewhere you control. If you can only do one thing on this page, do this one.
The database that was already public
On one site I picked up, the backups had been running faithfully every night for two years and landing in a folder the web server would happily serve to anyone who asked. A full copy of the database, customer records included, was a URL away. Nobody had done anything wrong exactly. Taking backups was somebody’s task. Thinking about where they landed was nobody’s.
The lesson I take from it is not about backups. It is that the things which hurt you are the ones that were never anybody’s job.
What not to do
Do not start changing passwords before you have a backup. If the site is on a host you cannot yet reach, locking someone out can leave you with a site you cannot administer and no copy of it. Copy first, then secure.
Do not let anyone talk you into an immediate rebuild. A rebuild is sometimes right, but almost never on day one, and anyone proposing it before they have looked at what exists is selling rather than diagnosing. The site you have is usually recoverable, and knowing that puts you in a much better position to decide.
Do not burn the relationship if you do not have to. People go quiet for ordinary reasons: illness, overload, a job, embarrassment about a job half done. A short, unemotional message asking specifically for domain and hosting access resolves this more often than a legal letter does.
Once you are back in control
Write down who owns what. One page, boring, kept somewhere other than the site itself: registrar, DNS, host, admin accounts, repository, and who to contact for each.
Then decide what you actually need. Not everyone needs someone on retainer. But if the reason this became a crisis is that nobody was watching the system between requests, then the fix is not another builder, because the next one will also finish and move on. I have written about the difference between a maintenance plan and a retainer, and about who owns systems after launch, because this is the situation both of those pieces are really about.
Ask what you would be unable to do
When it is calm again, ask the question that would have prevented all of this.
“If the person who built this disappeared tomorrow, what would I be unable to do?”
Whatever the honest answer is, that is your actual dependency. It is almost never the code. It is usually an account.
Put domain renewal on a calendar you control, not just on auto-renew tied to somebody else’s card. The most expensive outage I have seen was not a hack or a crash. It was a lapsed domain nobody had noticed was registered to a person who had moved on.