How much of your business walks out the door when one person does?

If that person is your only developer — a freelancer, an employee, or a one-person agency — the honest answer is: more than you think, but almost certainly less than you fear. Most post-departure panic comes from not knowing which of three situations you are in. Either they left things tidy and documented, or they left things working but opaque, or they left things broken and half-finished. You cannot tell which until you look. This article is about looking, calmly, in the right order.

One reassurance up front: systems rarely fail the day a developer leaves. Servers keep running, domains keep renewing, software keeps working. The risk is slower than that — knowledge decays, credentials lapse, and small changes become impossible. That slow pace is your friend. You have time to triage properly.

What typically breaks

Four things tend to walk out with a departing developer:

  • Knowledge. Why the system is built the way it is; which decisions were deliberate and which were expedient; what that cron job at 3am actually does.
  • Credentials. Admin logins, hosting accounts, domain registrars, third-party API keys — often registered to a personal email or held only in their password manager.
  • Deployment paths. How code gets from a laptop to the live system. If only one person ever ran the deploy, the path itself is a single point of failure.
  • Half-finished work. Branches nobody else understands, a migration started but not completed, a "quick fix" that was never quite finished.

Notice what is not on that list: the software itself, which usually keeps working. The exposure is in the ability to change and maintain it, not in its day-to-day operation.

Illustrative example: a 25-person distribution firm loses its freelance developer of six years. Nothing stops working on day one. Over the next month, though, the firm discovers the hosting account is in the developer's name, the domain renews in nine weeks under an email address nobody can access, and a half-finished stock-report change sits undeployed because the deploy process lived in the developer's own notes. None of this is sabotage — it is simply what "one person knew everything" looks like when that person leaves. Each item is recoverable, in order, once the firm knows it exists.

The calm triage sequence

Work through these four steps in order. Resist jumping ahead; each step depends on the one before.

  • Access and credentials inventory. List every account the business depends on: domain registrar, hosting, DNS, email, cloud services, payment gateways, app stores, third-party APIs, analytics. For each, establish who controls it, whether it is registered to a business or personal identity, and whether two people can currently get in. Move anything business-critical to business-owned accounts with named individuals as administrators.
  • Documentation reality check. Not whether documentation exists — whether it answers real questions. Pick the three things you most fear being unable to change, and try to follow the docs with a non-expert. Where they fail, record the gap. Do not attempt to document everything; prioritise by risk.
  • System health baseline. Establish what "normal" looks like: where the system runs, what it depends on, what backups exist (and when they were last restored, not just taken), what monitoring exists, what the monthly running costs are. This baseline is your reference point for everything afterwards.
  • Interim support. Only now decide how you will cover the next three to six months. That might be a retainer with another freelancer, a fractional arrangement, or hiring — but decide it with the inventory and health baseline in hand, not in a panic.

Constraints and trade-offs

Honest limits of triage, so expectations stay sane:

  • Recovery costs are front-loaded. The fortnight after a departure is the most expensive time to bring in help, because everything is unknown. A health baseline is cheaper to build before you need it.
  • You cannot fix everything at once. Inventory by risk, fix the top items properly, and schedule the rest. Spreading thinly across all gaps fixes none.
  • Reconstruction is detective work. Some knowledge is simply gone. A good engineer can usually infer intent from a running system, but this is slower than documentation and priced accordingly.
  • Avoid the rewrite reflex. The urge to "just rebuild it properly" is strongest right after a departure, and it is usually wrong. Understand what you have first; replace selectively, if at all.

Prevention, without bureaucracy

Once the immediate risk is contained, three habits prevent recurrence without imposing process theatre:

  • Documentation as a by-product, not a project. Require that anything built comes with a short note: what it does, how it is deployed, how it is monitored. Written for a competent stranger, not for the author.
  • Shared access as policy. Business-owned accounts, named administrators, recovery codes in a business-controlled vault. One person leaving should never lock the business out of its own systems.
  • An oversight rhythm. A regular, senior external look at the system — not to second-guess the developer, but so that at least one other person on the planet understands your setup. This is cheaper than a rescue and far less uncomfortable.

Your action checklist

  • Resist panic: the software usually keeps working; the risk is in the ability to change it.
  • Inventory every account, credential and renewal the business depends on.
  • Move business-critical access to business-owned accounts with named administrators.
  • Test your documentation against the three changes you most fear.
  • Record a system health baseline: hosting, backups, monitoring, running costs.
  • Arrange interim support for three to six months, chosen from evidence, not fear.
  • Adopt documentation, shared-access and oversight habits so this is the last time.

If you are in the middle of this right now, our technical review will work through the inventory, documentation reality check and health baseline with you, in that order. And if you would rather never be here again, our technical oversight service provides the regular senior external view that keeps one person's departure an inconvenience, not a crisis.