# Does your internal system depend on one person? > When an internal system depends on one person, the risk is not that they leave. It is what exists only in their head. Four layers to move out before they go. - Author: Marlon Trettin - Published: 2026-10-19 · Updated: 2026-10-19 - Language: en - Canonical: https://yowpi.com/en/blog/does-your-internal-system-depend-on-one-person --- If your internal system depends on one person, the risk is not that they leave. It is what exists only in their head: the passwords, the code nobody else has opened, the way a fix gets deployed and the reason behind each rule. Deciding that all of this lives in the company is architecture, and that decision comes before the resignation letter. ## TL;DR - In a study of 133 popular open source projects, [65% depended on two people or fewer](https://arxiv.org/abs/1604.06766) to keep from stalling. Concentrating knowledge in a few people is common in software, even when the code is public. - In an analysis of more than 36,000 projects, [89% lost their core team at least once](https://arxiv.org/abs/2412.00313), and among the abandoned projects only 27% managed to attract a new core developer. - The dependency has four layers: access, code, environment and decisions. Each one can be taken out of the person and put in the company's name. - Hiring an employee, a contractor or a studio does not solve this on its own. What solves it is defining, in writing, what has to stay with the company when any of them leaves. ## Why does one person leaving stall an entire system? Because in most small and mid-sized companies, the internal system was born from someone who did everything. They wrote the code, signed up for the server, registered the domain, built the integrations and settled the business rules in hallway conversations with the owner. It worked. That is why nobody touched it. The problem shows up the day that person resigns, gets sick or simply stops answering quickly. That is when the company finds out the system is theirs on paper and someone else's in practice. Small companies make this more likely, not less. According to Eurostat, [external suppliers performed the ICT functions in 70.19% of small EU enterprises in 2023](https://ec.europa.eu/eurostat/statistics-explained/index.php?title=ICT_specialists_-_statistics_on_hard-to-fill_vacancies_in_enterprises), and only 14.04% of small enterprises employed an ICT specialist in 2024. In most small firms, nobody on the payroll is an ICT specialist, and the technical work sits with an outside supplier who can move on with little notice. ## What does the data show about concentrated knowledge? That it is the normal state of a software project, even where everything is in plain sight. Software engineering measures this with the truck factor: the minimum number of people who have to leave before a project stalls. Researchers at the Federal University of Minas Gerais computed it for [133 popular projects hosted on GitHub](https://arxiv.org/abs/1604.06766). In 65% of them, it was one or two people. A study released in December 2024 widened the sample to [more than 36,000 open source projects](https://arxiv.org/abs/2412.00313). The authors found that 89% lost their core team at least once, that 70% of those losses happened in the first three years of the project and that most projects rely on a single core developer. Of the abandoned projects, only 27% managed to attract someone to take that place. These numbers come from open source, and that matters. These are projects where the code is published, the history is visible and anyone can study what was done. There is no equivalent public measurement for the internal systems of smaller companies. What can be said is the direction of the difference: in an internal system the code is usually closed, the history sometimes does not exist and the only possible reader is the person who wrote it. ## Is the dependency on the person or on what they carry? On what they carry. And what they carry splits into four layers, each with one objective question. ### Access In whose name are the domain, the server account, the code repository, the database and the integration keys? If the answer is one person's name or personal credit card, the company does not control its own system. This is the cheapest layer to fix and the most expensive one to discover late. ### Code Is the code in a company repository, with a change history, or on a personal machine and a shared folder? Code without history shows what the system does today and hides everything that was tried and undone. ### Environment Can someone else put a fix into production without calling the person who wrote it? If deployment depends on a step only one person knows how to do, the system can be perfectly documented and still grind to a halt. ### Decisions Why is the discount calculated that way? Why is that field mandatory? The study ["Bus Factor In Practice"](https://arxiv.org/abs/2202.01523), presented at ICSE 2022 with responses from 269 engineers, showed that project knowledge also travels through code reviews and meetings, not only through the code. In a smaller company, that channel is usually a hallway conversation, and it is recorded nowhere. The [guide to documenting and versioning corporate automations](/en/blog/how-to-document-and-version-corporate-automations) describes a lightweight format for that record. The four layers have an order. Access comes first because without it the other three are useless. Decisions come last because they take the longest, and they are the layer that lets a successor understand the system instead of merely opening it. ## An example, and it is a hypothesis Picture a distribution business with a few million in annual revenue. Three years ago, an independent contractor built its order system. He is responsive, knows the operation, and the system runs without notable incidents. He announces he has accepted an offer and will leave in four weeks. At the first handover meeting, the company finds out that the domain is registered in his name, the server is billed to his personal card, the code sits in a repository under his account and the sales commission rule was agreed by text message with a director who has since left. None of this is bad faith. It is the natural result of three years in which nobody asked whose name things were in. The four weeks go into transferring accounts, and no time is left to transfer understanding. The situation is invented. What happens after it is not. [Colo Saúde](/en/cases/colo-saude) came to Yowpi with a platform built by a previous vendor, with no technical owner and nobody on the team who knew it from the inside. The first project was a rescue: a security audit and performance work, before any new development. In another project, a public transport control system, the software had been written by the client's own founder, and the work was fixing bugs and connecting a new frontend to the existing system, without rewriting it from scratch. ## Does hiring or outsourcing change this risk? It changes the shape, not the existence. An employee can leave with a few weeks' notice. A contractor, with less. A studio can end the contract or rotate the team. In every case, the question that protects the company is the same: what stays with it the day after? The difference is in what the company can require. From an employee, through internal policy. From a vendor, by contract: accounts in the client's name from day one, code in the client's repository, a written deployment process and business decisions recorded next to the code. Any of the three choices needs that clause to avoid turning into a dependency. ## Four questions to ask this week You do not need an audit to start. You need a one-hour conversation with whoever maintains the system today, built on these four questions: 1. Which accounts does the system use, and in whose name is each one? 2. Where is the code, and does anyone besides the maintainer have access to it? 3. If the maintainer were away for two weeks, who could deploy a fix, and how? 4. Which three rules in the system raise the most questions, and where is the reason for them written down? The answers show which of the four layers leaves your company exposed. If the first question already turns up an account in someone's personal name, you have reason enough for the second conversation. ## Frequently asked questions **I have nobody technical to check the answers. Where do I start?** Start with the access layer, which requires no technical knowledge. Ask for the list of accounts and check whether the account holder is the company. You can verify that yourself by looking at invoices and registrations. The other layers need someone who reads code, and that is where an outside assessment is worth it. **Doesn't outsourcing to a studio just swap one dependency for another?** It does, if the contract does not say what stays with you. Dependency on a vendor is manageable when the accounts are in your company's name, the code is in your repository and the decisions are recorded. In that scenario, changing vendors is work, but possible. Without it, you start over. **The system works and the person has no plans to leave. Is it worth touching now?** Yes, precisely because the conversation is easy now. With the person available, transferring accounts and recording decisions is short, collaborative work. Once they leave, the same work becomes reverse engineering, which is slower and does not always recover the reason behind the rules. ## The next step If the answers showed layers that still sit with one person, the [Operational Architecture Diagnostic](/en/contact) is a 30-minute conversation to map those layers and the order in which to move them.