On a Tuesday morning, the only developer who understands the website, CRM integration, hosting, DNS and custom plugins hands in their notice.
The site continues to load. Then Marketing encounters an unfamiliar deployment error, IT discovers uncertainty about a hosting account and a client-portal request waits because the relevant knowledge belonged to one person.
The source calls the developer Matt and says Distinction has seen this shape at four firms in 18 months. Verify that record before using it as prevalence. The scenario remains an effective way to expose a planning risk: service continuity includes the ability to change, patch and recover a platform, rather than merely seeing it online today.
Key-person dependency grows through sensible local choices
Custom code is not inherently irresponsible. A developer may adapt a plugin, create a data mapping or automate deployment for sound reasons. Risk accumulates when the reasoning, access and operation stay in one person's memory.
Professional services firms are particularly exposed when technology is important and the internal team is small. The developer may work autonomously under a manager who cannot assess documentation or succession. Day-to-day competence hides the concentration.
The source cites developer job-search and tenure statistics without reliable current sources and then treats departure as highly probable. Remove those numbers. Absence can arise from resignation, illness, leave, supplier failure or simple unavailability. Continuity should not depend on predicting why.
What actually becomes unsafe
Change stops. Editors may manage routine content while structural, configuration or deployment work waits. The platform fossilises as the organisation changes around it.
Security response slows. A disclosed vulnerability may require inventory, risk assessment, test, deployment and monitoring. If access or the release process is unknown, the organisation cannot act confidently. Security owners should decide urgency and compensating controls.
Integrations fail without an audience. API, certificate, credential or data-model changes can interrupt CRM, forms, identity or reporting. Monitoring must surface the failure to someone able to respond.
Recovery relies on personal accounts. Domains, hosting, source repositories, deployment systems and supplier accounts may be registered to an individual or protected by a device nobody else can reach.
A replacement begins with archaeology. A capable new person still needs architecture, environment and decision context before making safe changes. The source's four-week agency recovery, three-week enquiry loss and 11-day access case all require project records and client permission. They illustrate plausible mechanisms, not benchmark timings.
Run a continuity exercise
Choose a critical system and assume the primary person is unavailable now.
Can the organisation:
- Identify business and technical owners?
- Access firm-owned domain, hosting, code, deployment and supplier accounts?
- Understand architecture, integrations and data flows?
- Deploy a low-risk change through the approved route?
- Apply and verify an urgent update?
- Detect and recover an integration failure?
- Contact suppliers and use contractual support?
- Restore from backup and validate the result?
The source calls this a bus test. Some teams prefer “lottery test” or “key-person test”; the point is tested continuity, not the imagined event.
Do more than inspect a document. Ask a second authorised person to perform a safe task using it. Record gaps and update the runbook. Untested documentation is a claim about recoverability.
Document decisions and operations
Useful documentation enables a competent person to act without relying on private memory. It can include:
- System purpose, owners and critical journeys
- Architecture and integration diagrams
- Repositories, branches and release process
- Environments and configuration ownership
- Monitoring, alert and incident routes
- Backup and recovery
- Dependencies, versions and support status
- Known debt, workarounds and open risks
- Supplier and renewal information
- Decision records for unusual choices
Do not put secrets in ordinary documentation. Store credentials, keys and recovery codes in a managed firm-owned system with least privilege, audit and appropriate break-glass access. Security should design the arrangement.
Documentation is part of delivery acceptance. Keep it proportionate and update it when the system changes. A 100-page manual nobody trusts is weaker than current task-based runbooks and a clear architecture record.
Distribute capability through practice
More than one person should be able to perform critical tasks. That can mean another employee, an approved external partner or a combined arrangement.
The backup person needs current access and experience. Use paired releases, rotation, recovery exercises and planned absence to test the system. Avoid creating two people who each hold different private halves of the knowledge.
External retainers can provide continuity if the partner has actually been onboarded, has controlled access, understands the estate and has a realistic response agreement. A monthly invoice alone is not insurance.
Distinction should apply the same standard to itself. The source admits that earlier delivery pressure sometimes pushed documentation aside and states that clients should not depend on Distinction. That candour is stronger than a claim that current documentation is always non-negotiable. Verify present practice and preserve the accountability.
Decide whether architecture compounds the risk
A heavily customised or obscure stack can make recruitment and handover harder. A widely adopted platform can still be opaque when poorly implemented.
Assess:
- Availability of current skills and supplier support
- Degree and necessity of customisation
- Standard export and portability
- Support status and upgrade route
- Automated tests and deployment repeatability
- Separation of content, data and presentation
- Cost of continuing, reducing debt or migrating
The source names several CMS products and suggests a migration might take two sprints. Product suitability and effort cannot be generalised. Replatform only when evidence shows the current risk and total economics justify it. Documentation and access work usually belongs in either path.
Put digital continuity on the risk register
Describe the affected service, key dependencies, potential impact, existing controls, owner and next test. Avoid unsupported comparisons with other board risks.
Mitigations can include firm-owned accounts, access review, current runbooks, cross-training, supplier support, recovery tests and architecture change. Retention and good employment practice also matter, yet they do not remove the need for continuity.
The goal is not to distrust a valued developer. It is to avoid making their continued availability a control.
Distinction offers a platform dependency review. The source's promise that an hour will identify the plan needs confirmation as a current service statement. A useful review should produce an ownership map, tested gaps and proportionate mitigations, not use key-person anxiety to make migration inevitable.
