What to Do When Your Software Developer Is No Longer Available

The first task is not technical — it is establishing who in the business has legitimate, authorised access to whatever accounts exist, and confirming that a recent, working backup actually exists somewhere the business controls. If the departed developer held the only login to hosting or the database, this is the moment to start the account-recovery process with whichever provider holds it, using whatever proof of business ownership that provider requires.

Imagine a coworking space whose booking and door-access system was built and personally hosted by a single freelance developer, who then stopped responding to messages. The space's operator does not yet know whether they have a current backup of member and payment data, or only whatever the system happens to display on screen right now — so the very first call is to the hosting provider, to establish account ownership and pull whatever backup exists before anything else changes.

Next, build a complete inventory of everything the software touches: the hosting provider and server, the domain registrar, the code repository (and who has access to it), and every third-party integration — payment gateway, SMS or email service, mapping or accounting API. Each of these may be billed and controlled separately, sometimes on the departed developer's own personal account rather than the business's.

This inventory rarely comes from a single document. It usually has to be reconstructed from bank and card statements (recurring charges to hosting or API providers are a good starting clue), browser-saved passwords on any company device the developer used, and DNS records for the domain, which will show which servers and email providers are actually in use even without direct access to an admin panel.

While the inventory is underway, write down — even roughly — what the software is essential for right now: which processes would stop working today if the current server or account access were lost. This is not a technical document; it is a business-continuity note that tells whoever picks this up next what actually needs to keep running versus what can wait.

Flag immediate risks separately: a domain about to expire, an SSL certificate close to lapsing, a hosting bill that has not been paid because no one knew it existed, or an API subscription approaching its limit. These items can cause an outage on their own, independent of anything wrong with the application's code.

Once access and the immediate risks are under control, bring in a replacement team to do a controlled assessment before committing to any major direction — repair, modernise, or rebuild. Resist the urge to have a new team start changing code on day one; the assessment period exists specifically to build an accurate picture of what exists before acting on it.

This is close to a formal codebase audit, and it benefits from the same discipline: reproduce the application in an isolated environment, map its dependencies, and identify what is fragile before making structural changes to it.

The experience of losing access to a single developer is, itself, the strongest argument for not depending on one person again. Establish clear company ownership of the domain, hosting account, code repository and any paid API subscriptions — under accounts the business controls directly, not an individual's personal login.

Alongside that, put a basic continuity routine in place: written documentation of how the system is deployed, a second person with working access even if they are not the primary maintainer, and a habit of reviewing that access list whenever a working relationship — employee or contractor — ends.