What happens to our custom software if the developer who built it disappears?
The code is usually the least of it. What breaks a company is the knowledge and access that lived with one person: a scheduled job on an unnamed machine, an API key in a personal account, a deploy nobody else has performed. Fix it by moving every account into company ownership, scripting the deploy, and having a second person release a trivial change on a schedule.
The risk is access, not authorship
If your code is in a repository your company owns, another competent developer can read it. Slowly, perhaps grumpily, but they can. What they cannot do is guess a credential, discover a cron job on a server nobody remembers, or reconstruct which vendor account an integration was registered under.
So the useful audit is not about code quality. It is about whether anything essential is reachable only through one human being.
The five places single-person dependency hides
- Personal accounts. A domain registrar, cloud console or app registration under someone's own login. Common, and catastrophic at exactly the wrong moment.
- Undocumented scheduled jobs. The nightly script that generates the report everyone relies on, running somewhere unlisted.
- Manual deploys. If releasing involves steps only one person knows, only one person can fix an urgent bug.
- Undocumented business logic. The rule that excludes certain job types from a report, implemented once and explained to nobody.
- Vendor relationships. Support accounts and API access opened under an individual's email address rather than a company one.
A drill, not a document
Continuity plans written and filed are usually fiction. Test instead. Once a quarter, have someone other than the primary developer deploy a trivial change to production, following only the written procedure. Whatever they get stuck on is your actual gap.
The same drill applied to a restore is even more valuable. A backup that has never been restored is a belief, not a backup, and the moment you learn otherwise is always the worst possible moment.
Reduce the surface you have to remember
Fewer moving parts means fewer things that can be known by only one person. Configuration checked into the repository, infrastructure defined in files rather than clicked into a console, and scheduled work running in a visible, monitored place all shrink the tribal knowledge required.
This is one of the practical reasons to prefer a maintained platform for the common parts and custom work only for the specific parts — the shared components are already documented and supported by more than one person. It is the same tradeoff described in platform versus custom, and it is why we insist that custom builds ship with a handoff package rather than a phone number.
Topics: continuity · bus factor · access · risk
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.