Reduce key-person risk by finding each dependency and moving it from a person to the company.
Key-person risk in technology is the chance that the business stalls when one person leaves, falls ill, or stops answering. Hiring alone rarely fixes it. The fix is a sequence: find each dependency, move access and credentials into accounts the company controls, write down how things run, spread the knowledge across more than one person, and then test the result as a buyer would.
Find the dependencies by tracing the processes that bring in revenue and close the books: quoting, scheduling, order entry, billing, and reporting. For each one, ask who would be called if it broke on a busy morning. Then look for the less obvious ones: a founder’s personal email as administrator on the domain or hosting, a script that runs on one laptop, a pricing spreadsheet only its author understands.
Record each dependency in one list with the system, the person, what they know or control, and the consequence if they were unavailable. Rank the list by business impact rather than technical interest. A missing runbook for an internal report matters less than a single login controlling the payment processor, even if the report takes more effort to fix.
Move access and credentials into accounts the company controls.
The most urgent step is administrative access. Every critical account, including the domain, email, hosting, code repository, accounting system, and payment processor, should have at least two named administrators from the company, using company email addresses and multifactor authentication. Personal accounts that hold business systems should be moved to company accounts, with care taken not to interrupt service during the change.
Credentials belong in a company password manager with shared vaults by function, not in a developer’s notes or a browser. Credentials used by integrations should be listed, tied to service accounts rather than individuals, and rotated when a person with access leaves. Where a vendor contract names a person as the account contact, change it to a role that survives turnover.
Treat the source code the same way. Custom applications should live in a repository under a company organization account, with the deployment process documented and runnable by someone other than the original developer. Ask counsel to confirm what existing development agreements say about the code and the accounts, since those terms affect what can be moved and how.
Write runbooks that let someone else operate each system.
Documentation that reduces key-person risk is practical rather than comprehensive. For each critical system, write how to deploy a change, how to restore from backup, how to rotate a credential, what the scheduled jobs do, and what to check when something fails. A new person with reasonable skills should be able to follow the runbook without calling the original author.
Keep a current system map alongside the runbooks: every application, what it is responsible for, which integrations connect it to others, where its data lives, and who supports it. The map is what a new leader, a new vendor, or a buyer’s reviewer reads first. It also makes the next dependency visible as soon as a new system is added.
Test the documentation by using it. Ask someone other than the author to perform a deployment or a restore from the written steps, and fix every gap they hit. A restore that has never been rehearsed is an assumption, and a runbook that has never been followed usually leaves out the step the author performs from memory.
Spread knowledge so no single person is the only one who can act.
Documentation lowers the risk, and a second capable person removes much of what remains. For each critical system, name a primary and a backup who can deploy, restore, and troubleshoot. The backup should do real work on the system on a regular schedule, not only read about it, so their knowledge stays current as the system changes.
When the dependency is an outside developer or agency, ask for pairing sessions with an internal person or a second firm, recorded walkthroughs of the architecture, and changes made through reviewed pull requests rather than direct edits in production. Code review spreads knowledge as a matter of routine, because every change is read by at least two people before it ships.
Handle the person at the center of it with care. The developer or analyst who built the system is often proud of it and anxious about being replaced. Framing the work as protecting the business and easing their support burden, and recognizing their role in the transition, tends to produce a better handover than treating them as a risk to be removed.
Test the result the way a buyer will at exit.
Buyer diligence tests for key-person risk directly. Reviewers ask who maintains each system, who holds administrative access, whether another team could support the code, and what happens if a named individual leaves. They interview the people involved and look for gaps between what management describes and what the accounts and repositories actually show.
Run the same test internally well before a sale process. Have someone outside the regular team try to answer those questions from the system map, runbooks, and access lists alone. Where they cannot, the gap is a finding. Track each finding to closure and keep the evidence, such as administrator lists and restore records, ready for the data room.
For a custom application that only one developer or agency has maintained, an independent code assessment helps show whether another team can support it. Baybloom Software takes over and stabilizes existing applications in this situation. Whoever does the work, the aim is the same: a company whose technology keeps running when any one person steps away.
Put it into practice
Talk through the project you are considering.
Bring the workflow, the systems around it, and the questions you need to resolve. We can help define a useful next step.
Discuss your project