A build decision is quietly a bet on two people’s career plans.
In this guide
Key Takeaways
- →The bus factor for most internal tools is one. What makes strategy software different is that an interruption lands on planning cycles and performance conversations.
- →Confidence is more fragile than uptime. Once teams keep side spreadsheets, the system becomes a formality, and that trust takes longer to rebuild than the fault took to fix.
- →Documentation captures what, not why. The trade-offs, the production edge cases and the fragile parts live in the builder’s head and leave with them.
- →The practical dependencies are checkable today: account ownership, deployment, credentials, certificate renewals. Each is cheap to fix now and expensive to find during an incident.
- →Mitigating it properly means documentation, shared ownership, rotation and a third engineer, at which point you are running a small software team for a product that is not your business.
What Is Key Person Risk in Software?
Key person risk is the exposure created when a system depends on individuals rather than structure. In strategy software it is unusually costly, because an interruption lands on planning cycles and management reviews, and the confidence lost is harder to rebuild than the fault that broke it.
Imagine a familiar scenario. An organization has run its strategy process on an internal app for eighteen months. Two engineers maintain it. One of them, the person who built most of it, accepts an offer from a larger company. They give notice, spend a few weeks writing documentation and handing over, and leave.
On paper, the handover is complete. In practice, the remaining engineer now owns a system they only partly understand, the organization has started recruiting a replacement who will take months to find and longer to become effective, and the next quarterly planning cycle begins in five weeks.
Every organization knows that depending on a single individual is risky. Engineers sometimes describe this with a grim metric called the bus factor: the number of people who would have to disappear before a project could no longer continue. For many internal tools, the honest answer is one.
What makes strategy software different is what depends on it. A failing internal reporting tool is an inconvenience. A failing strategy system disrupts planning cycles, management reviews, and, where strategy feeds performance management, conversations about people’s careers and pay. The cost of an interruption is measured in leadership time and organizational confidence.
Confidence is the more fragile of the two. A strategy program depends on people trusting that the system reflects reality and will be there next quarter. Once teams experience an outage during planning, or see numbers they know are wrong, they start to hedge. They keep side spreadsheets, delay updates, and treat the system as a formality rather than a tool. Rebuilding that trust takes far longer than fixing the technical fault that broke it.
Engineers Move, and They Should
This is not a criticism of engineers. Good engineers are in demand, and they rightly move on for better opportunities, more interesting problems, and career growth. Maintaining an internal goal-tracking app is rarely anyone’s long-term career ambition, which makes it more likely, not less, that the people doing it will eventually leave.
An organization that builds its strategy process on a small internal team is therefore making a bet on retention, usually without realizing it. It is a bet that gets harder to win the longer the system runs.
Documentation Captures What, Not Why
The standard response to key-person risk is documentation. It helps, and it is never enough. Documents describe what the system does and how to run it. They rarely capture why it was built that way: the trade-offs considered, the edge cases discovered in production, the fixes that were made to keep one team happy, and the parts that are fragile and should not be touched.
That understanding lives in the builder’s head. When they leave, the next person has to rediscover it, usually by breaking something. With AI-generated code, as the next article explores, the problem is even sharper, because parts of the system may never have been fully understood by anyone.
The Vacancy Always Arrives at the Wrong Time
Departures do not wait for convenient moments. They tend to cluster around the same times as other changes: after bonus payments, at the start of a new year, during reorganizations. Those are often the periods when a strategy system is under the most pressure, as teams set new goals and leaders prepare reviews.
During the vacancy, requests pile up. Small problems that the departed engineer would have fixed in an hour take days. Users notice, lose confidence, and start keeping their own spreadsheets as a backup, which quietly undermines the purpose of having a system at all.
Hiring a replacement takes longer than most plans assume. Finding an experienced engineer who is willing to maintain an internal tool can take months, and once hired, they need further time to learn the system. Across that whole period, the organization is running its strategy process on a system with reduced support, while hoping nothing important breaks.
The Hidden Single Points of Failure
Key person risk is not only about knowledge. Look closely at most internal apps and you will find practical dependencies on individuals: the cloud account opened with someone’s work email, the deployment process that only one person has run, credentials stored in a personal password manager, a domain or certificate that renews to an address nobody else monitors.
Each of these is a small risk on its own. Together, they mean that a single departure can leave the organization unable to update, deploy, or even fully access its own system. Discovering this during an incident is common, and expensive.
The Single-Points-of-Failure Checklist
| Single point of failure | What it looks like | How to check it today |
|---|---|---|
| Cloud account ownership | The account was opened with one person’s work email | Who is the billing owner and the root user? Could a second person sign in right now? |
| Deployment | Only one person has ever shipped a release | Ask somebody else to deploy a trivial change this week, and watch whether they can |
| Credentials | Keys and passwords sit in a personal password manager | Is every secret in a shared vault the team can reach without asking one individual? |
| Domain and certificates | Renewal notices go to an address nobody else monitors | Where do expiry warnings land, and who else receives them? |
| Design rationale | The trade-offs and production edge cases live in the builder’s head | Can a second person explain why a given part works the way it does? |
| Fragile areas | Known informally as the parts not to touch | Is that warning written down anywhere, or only remembered? |
| Bus factor | Nobody has ever counted it | How many people would have to leave before the work stops? Write the number down |
The right-hand column is the point. Every one of these can be checked this week, while everything is still working, and each is far cheaper to fix now than to discover during an incident.
See Continuity That Does Not Depend on One Person
How to Reduce Key Person Risk
The risk can be reduced. Organizations can require thorough documentation, insist on shared ownership of every account and process, rotate responsibilities, and add a third engineer so that no single departure is critical. Each of these is sensible.
Each also adds cost and effort, and together they move the internal app further from the cheap, quick solution it was meant to be. At some point, the organization is running a small software team with proper processes for a product that is not its business. That is exactly what a specialist vendor already is, and it is the core-versus-context trade-off the position paper for this series sets out.
Why a Vendor Carries This Risk Differently
A specialist vendor is not immune to staff turnover. The difference is that it is built to absorb it. Knowledge is spread across product, engineering, support, and customer success teams. Processes, tooling, and documentation exist because many people work on the platform at once. When one person leaves, the platform does not depend on them.
There is also a difference in commitment. A vendor is contractually bound to deliver the service, and commercially motivated to keep customers successful, because its revenue depends on renewal. An internal team member has no equivalent obligation, and their incentives point toward their next role rather than your next planning cycle.
This is the core asymmetry. With a vendor, continuity is a structural property of the relationship: it is written into the contract, staffed across teams, and reinforced by the vendor’s need to keep your business. With an internal build, continuity depends on individual people choosing to stay. One arrangement is designed to outlast any individual. The other is designed around them.
At Profit.co, the answer to the question below is already written down. Support runs 24/7, the platform’s behavior is documented in a help center rather than in one engineer’s memory, and hosting, credentials and certificate renewals are run by the vendor rather than kept in one person’s password manager. The checklist above becomes the vendor’s job.
Key person risk is easy to ignore while everything is working, which is exactly when it is cheapest to address. The question to ask now is simple: if the person who knows the most about your strategy app resigned tomorrow, what would happen to your next quarterly review?
For AI-built systems, the answer has an extra complication. Sometimes even the person who built the app does not fully understand it.
Make Continuity Structural, Not Personal
Frequently Asked Questions
The exposure created when a system depends on specific individuals rather than on structure. Engineers measure it as the bus factor: how many people would have to disappear before the work could not continue. For most internal tools the honest answer is one.
Thorough documentation, shared ownership of every account and process, rotated responsibilities, and enough people that no single departure is critical. Each is sensible, and together they move an internal app a long way from the cheap, quick solution it was meant to be.
Because documents capture what a system does and how to run it, not why it was built that way. The trade-offs considered, the edge cases found in production and the parts that are fragile live in the builder’s head, and the next person usually rediscovers them by breaking something.
Account ownership tied to one person’s work email, a deployment process only one person has run, credentials in a personal password manager, and domain or certificate renewals going to an unmonitored address. Together they can leave an organization unable to update or even access its own system.
Because of what depends on it. An interruption disrupts planning cycles and management reviews, and where strategy feeds performance management it reaches conversations about careers and pay. The confidence lost is harder to rebuild than the technical fault that caused it.
They are not immune to turnover, but they are built to absorb it. Knowledge sits across product, engineering, support and customer success, and continuity is written into a contract. With an internal build, continuity depends on individuals choosing to stay.
