Plenty of good software is built and looked after by one person: a freelancer, a co-founder, a single in-house developer who has been there from the start. That is not a problem in itself. The problem is what happens if they leave, fall ill, or simply stop answering.
If the honest answer is “we would be stuck”, your business has key-person risk. It is common, and it is very fixable.
Signs you might have it
- Only one person can release a new version.
- Only one person knows the passwords, or they live in that person’s head or personal password manager.
- Accounts for hosting, code or app stores are in that person’s name.
- Nothing is written down about how the system fits together.
- Every question, however small, waits for the same person.
Any one of these is worth fixing. Several together mean the business depends on someone’s continued goodwill.
Why it happens
Nobody plans it. In the early days, speed matters more than documentation, and the person building the product is the obvious one to hold the keys. Years later, the business has grown around a single point of failure that nobody ever decided on.
How to reduce it, kindly
Start with the framing. This is not a question of trust; it is the same reason a business has more than one key to its front door. Most developers welcome it, because it also means they can take a holiday.
- Move accounts into the company’s name. Code, hosting, domains, app stores, email services. Give the developer access through the company’s account, not the other way round.
- Put secrets somewhere shared and safe. A business password manager, with at least two people able to get in.
- Write the essentials down. How to set the system up, how to release, where the important settings live, and what to do when the usual things go wrong. A few pages is enough to start.
- Make releasing repeatable. If a new version can be published by following written steps, or by an automated process, it no longer depends on one person’s memory.
- Have someone else look. A second developer, even occasionally, who can read the code, run it and release it, turns a single point of failure into a team.
The test
The simplest test is the honest one: if your developer were unreachable for a month starting tomorrow, could someone else keep the product running and ship an urgent fix? If the answer is yes, you are in good shape. If it is no, you now know exactly what to work on.