What to Do When Your Software Developer Is No Longer Available

Start with people, not code. Find out who in the business holds legitimate, documented access to the hosting account, the database and the domain registrar, and write each name beside the account it controls. Then confirm a recent backup exists. If the developer owned the only login, open an account-recovery request with that provider and send the proof of business ownership it asks for, such as registration papers.

Take a coworking space whose keycard readers, booking calendar and invoice PDFs run on software hosted by one freelancer who has stopped answering messages for two weeks. Nobody knows whether a backup exists. The operator’s first call goes to the hosting provider, to establish who owns the account and to download any stored backup before another change is made to the server.

Write down what you find. Record the account name, the email address on it, the renewal date and the card that pays for it, because those four facts decide how fast recovery can move.

Next, list everything the software touches. That covers the hosting provider, the domain registrar, the code repository and its members, and every paid integration, such as a Stripe webhook or a Twilio number. Some of these accounts may sit under the departed developer’s personal email rather than the business’s, which means a bill can lapse without anyone seeing the warning.

No single document holds this list. Rebuild it from bank and card statements, where recurring charges to hosting or API providers are the best clue, and from saved passwords in a company laptop’s browser. DNS records come next. A lookup on the domain shows, through its A, MX and SPF records, which servers take web traffic and which provider sends email, even without registrar access.

Annual items hide easily. Treat the list as unfinished until a second person has checked it against twelve months of bank statements, because forgotten annual renewals are the usual surprise.

Write a continuity note now. List every process that would stop if the current server or account access disappeared, such as keycard sync, booking confirmations, member logins or the CSV export to accounting. Rough notes are fine. The note tells whoever picks up the work which functions must stay online and which can wait a week, so nobody spends the first days on the wrong problem.

Flag live risks separately. An expiring domain, an SSL certificate about to lapse, an unpaid hosting invoice or an API plan near its limit can each take the site offline. Put dates next to each.

Once access and live risks are under control, hire a replacement team for an assessment before choosing between repair, modernisation and rebuild. No code changes on day one. The assessment exists to build an accurate picture of what is running, because a team that edits before it understands can turn a stable system unstable.

Treat it as a small codebase audit. Reproduce the application in an isolated environment with anonymised data, map its libraries, cron entries and queue workers, and mark parts that look fragile before anyone proposes a change. Agree the assessment scope in writing. Name the questions it must answer, such as whether the code compiles, where the data lives and how long the most urgent fix will take.

Never rely on one person again. Move the domain, hosting account, code repository and paid API subscriptions under company-owned logins with two-factor codes sent to a shared mailbox, so they survive the next departure.

Add a basic continuity routine. Keep written notes on how the system is deployed, give a second person working access even if they never maintain it, and review the access list whenever anyone leaves. Check it each quarter.

Run a recovery drill. Ask the second person to restore last night’s backup to a spare environment and log in, because a backup nobody has restored is only a hope.