What happens if your developer disappears?

The key-person risk hiding inside software

A business can own its product commercially while lacking practical control of the system. The only developer may hold the cloud account, know the deployment sequence, understand an undocumented database job, or receive every production alert. The risk becomes visible when that person is sick, leaves, becomes unavailable, or the commercial relationship deteriorates.

This is often called key-person or bus-factor risk. It is not a judgment about the developer. It is a governance condition: essential business operations depend on knowledge or access that the organization cannot reliably replace.

Put critical accounts under company control

Inventory the systems required to operate and recover the product: source control, cloud hosting, domains and DNS, databases, email, payments, analytics, monitoring, app stores, certificates, model providers, and support tools. The legal business should own the primary account wherever possible.

Use role-based access and individual identities instead of shared passwords. Protect account recovery with company-controlled email addresses and more than one authorized administrator. Store emergency credentials in a managed password vault with a tested break-glass process.

• Confirm billing and renewal contacts.
• Record account owners and backup administrators.
• Remove dormant collaborators and agency accounts.
• Test recovery methods without locking out the team.
• Document where audit logs are available.

Build an operational map

A handoff needs more than a code tour. Create a concise map of repositories, services, environments, data stores, queues, scheduled jobs, external integrations, domains, and deployment paths. Identify which components are critical to revenue or customer access.

For each component, record its purpose, owner, access method, failure symptoms, monitoring location, and recovery action. Architecture diagrams are useful when they describe the deployed system rather than an aspirational design.

• How a change moves from local development to production.
• Which tests and approvals block a release.
• How configuration differs by environment.
• Where logs, alerts, and dashboards live.
• How to roll back code and database changes.

Prove backup and recovery

A backup is only useful if it contains the required data, can be located during an incident, and restores within the business’s tolerance for downtime and data loss. Define recovery time and recovery point objectives in business language, then choose controls that support them.

Perform a restore test into an isolated environment. Record the exact steps, duration, dependencies, and problems encountered. Repeat the test on a schedule and after material architecture changes.

Run a real handoff test

Ask a second qualified person to set up the application from the documentation, deploy a harmless change to staging, locate a recent production error, identify the owners of critical vendors, and explain the recovery process. Observe where they require undocumented assistance.

Turn each gap into a concrete task. Prioritize missing access, unrecoverable data, unknown production components, and deployment steps that exist only in memory. Record lower-risk cleanup separately so the continuity plan remains actionable.

• Can they build and test the application?
• Can they deploy and roll back safely?
• Can they find customer-impacting errors?
• Can they restore critical data?
• Can they contact every essential provider?

Keep continuity current

Review the continuity record when a key person joins or leaves, a vendor changes, a domain moves, a new data store is introduced, or the deployment architecture changes. A quarterly lightweight review is often more effective than an annual documentation project.

Track unknowns explicitly. A truthful record that marks an unverified restore is safer than a polished document that implies certainty. Assign every material gap an owner, a target date, and a way to verify completion.