Your system works great. As long as the person who knows why is still working.
Imagine a company that has had a system running for seven years. It was built in stages. First, a software house made it. Then part of it was taken over by a freelancer. Later, another team added a B2B module. The next agency connected the CRM. Someone else integrated payments.
The system works.
The company makes money thanks to it.
Employees use it every day.
Customers have no idea how many processes happen in the background.
There is just one problem.
No one really knows anymore, how all of this works.
The documentation is partly in Confluence. Something is on Google Drive. A few details are in tickets. One integration was described in an email from four years ago.
And the most important thing "Łukasz probably remembered".
But Łukasz left three years ago.
And for three years nothing happened.
Until one Tuesday morning.
The system works. So everything is fine?
This is one of the most deceptive states a company system can be in.
It works.
There are no failures.
Users are happy.
Sales uses the application.
Orders go through.
Data reaches the CRM.
Reports are generated.
So the natural reaction is: Let’s not touch it. Why mess with something that works?
And indeed - there is no reason to change a working system just because you can.
The problem is that a system can be technically stable and at the same time very unstable organizationally.
It may work today, but no one knows what will happen when you need to change the server, API provider, domain, library, authentication method, or a part of the business process.
It may be efficient, but dependent on one person.
It may be secure, but no one knows where all the access keys are.
It may be developed further, but only by the person who knows the history behind every decision.
And this is exactly where the concept of bus factor comes in.
How many people can disappear before the project starts having problems?
Bus factor is a very simple, though brutal, concept.
We ask: How many people must stop being available before the project can no longer be maintained efficiently?
If the answer is: "One", we have a problem.
If the answer is: "Two, but both work for another company", we have an even bigger problem.
Of course, this is not about people literally "disappearing".
A programmer may leave the company.
A freelancer may end the collaboration.
A software house may stop serving the client.
An administrator may change jobs.
The person responsible for a specific integration may move to another department.
The knowledge owner may simply get sick or be unavailable for a few weeks.
If the ability to understand the system disappears with them, the company does not have a staffing problem.
It has a business problem.
Code does not always say why something works
You might say: "After all, we have the source code. If need be, a new programmer can read it."
Theoretically, yes.
In practice, code mainly answers the question: how the system does something.
It does not always answer the question: why it does it that way.
And that is a huge difference.
In the code there may be a condition: "If the client has a specific account type, perform operation X."
A new developer may find it.
But how are they supposed to know why?
It could be a business requirement.
It could be a leftover from an old integration.
It could be a safeguard against an external API error.
It could be a workaround for a problem that occurred five years ago.
It could be a solution for an unusual case involving one of the biggest clients.
It could be there for a very good reason.
Or for none at all.
Without context, it is hard to judge.
That is why system documentation should not be limited to instructions:
"click here, then here".
The most valuable documentation often describes decisions and dependencies, not just feature usage.
The most dangerous knowledge is the kind that exists only in someone’s head
Companies very often have documentation. But documentation is not always the same as knowledge.
We may have an API description - but no information on why we use this API specifically.
We may have a deployment guide - but no list of all the places where the configuration needs to be changed.
We may have an integration description - but not know what will happen when the external provider changes the authorization method.
We may have a list of servers - but not know which one is critical for a specific process.
We may have access to the repository - but not access to the account where the production infrastructure is located.
These are exactly the elements that can turn an apparently simple change into a multi-day investigation.
An integration that has worked for five years is still a dependency
One of the most overlooked areas is external services;
- Payments.
- SMS.
- Email.
- CRM.
- ERP.
- Maps.
- Courier systems.
- Marketing platforms.
- Accounting systems.
- Cloud services.
- External APIs.
- Open source libraries.
Each of these things is part of a larger ecosystem.
If a system uses ten external services, we do not have one system. We have a system plus ten dependencies. And each of them can change.
The provider may change the API.
It may end the service.
It may change the pricing model.
It may retire the old version.
It may introduce new security requirements.
It may be acquired by another company.
That is why knowledge about the origin of components and software dependencies is also playing an increasingly important role. NIST points, among other things, to the importance of SBOM, or Software Bill of Materials - a formal list of components used to build software. Such a list helps understand what the system consists of and more quickly assess the impact of vulnerabilities or changes in the supply chain.
For business, this can be reduced to a very simple question:
Do you know what your system depends on?
And now imagine changing the software house
This is one of the moments when all the gaps come to light.
For years, the company worked with one contractor. Then suddenly the cooperation ends. There can be many reasons; strategy change. Budget change. Agency acquisition. Organizational problems. Lack of competence for further development. Or simply the company wants to work with another partner.
The new software house asks:
"Where is the repository?" - It is there.
"Where is the infrastructure?" - It is there.
"How do we deploy to production?" - "We don’t know, the previous team did it."
"How does the ERP integration work?" - "Probably through that server."
"What API keys do we have?" - "They should be in the email."
"Which APIs are production?" - "We don’t know."
"Which processes are critical?" - "You need to ask Łukasz."
Łukasz no longer works there...
And that is exactly why transferring a project is not just transferring code. Knowledge has to be transferred too.
Documentation is not a cost. It is an insurance policy
In many companies, documentation is treated as something you do "when there is time."
Which usually means never.
Or at the end of the project.
Or when someone asks.
That is a mistake.
Documentation is one of the mechanisms that reduce operational risk. It does not directly generate sales. It does not improve conversion. It does not look impressive in a presentation.
But in a crisis, it can mean the difference between: "we’ll fix it today"
and: "first we need to find the person who remembers how it worked".
In the new NIST guidelines on security, privacy, and software supply chain risk management, documenting the system’s purpose, its state, controls, and the responsibilities and behavior of the people who manage it is treated as part of orderly system management.
This clearly shows the change in thinking.
Documentation is not only a tool for developers.
It is an element of organizational continuity.
What should be documented?
This is not about creating 800 pages of documentation that no one will ever open.
Good documentation should primarily answer the questions that will come up when something changes or stops working.
- Who owns the system?
- Where is the code located?
- Where is production located?
- What does the deployment process look like?
- What environments are there?
- What are the critical integrations?
- What external services do we use?
- Who is their provider?
- What contracts and accounts do we have?
- Where are the keys and access data?
- Who has permissions?
- What does the backup look like?
- What does system recovery look like?
- What open source components are used?
- Which libraries are outdated?
- What are the most important architectural decisions?
- Which elements are critical to the business?
- What happens if a specific external service stops working?
This is not documentation "for programmers".
This is a map of the business’s dependence on technology.
"It works, so let’s not touch it" may be a strategy. But you need to know its price
Not every company needs to rebuild an old system.
Not every legacy system is bad.
Not every old codebase needs to be rewritten.
Quite the opposite - sometimes a stable, older system is a much better solution than an expensive migration done for no specific reason.
The problem is not the age of the system.
The problem is the lack of knowledge about its condition.
If we know how the system works, what its dependencies are, where the risks lie, and who can maintain it, we can consciously decide:
- we keep it,
- we modernize it,
- we rewrite a part,
- we migrate it,
- or we do not touch anything.
If we do not know that, the decision "we don’t touch it" is not a strategy.
It is a bet.
What does an audit of an inherited system look like?
When an existing system comes to a software house, the first step should not be: "Let’s rewrite it." - First, you need to understand it.
A good audit should cover, among other things, the application architecture, source code, database, infrastructure, deployment process, dependencies, integrations, security, access to services, and documentation.
But understanding the business is equally important;
- Which processes are critical?
- Which functions are used every day?
- Which modules are responsible for revenue?
- Which elements can be turned off without consequences?
- What happens when a specific integration stops working?
- Which elements are the riskiest?
Only after combining the technical and business perspectives can you say what really needs to change.
An audit does not have to end in a revolution
Sometimes the audit result is surprisingly simple.
The system is fine, it just needs:
- Documentation to be completed.
- Access to be organized.
- A few libraries to be updated.
- Ownership of accounts to be transferred.
- The deployment process to be described.
- Monitoring to be added.
- A backup to be established.
- A second person to be introduced to areas that only one developer knew.
And suddenly the bus factor changes from 1 to 3.
There is no need to rewrite the entire application.
There is no need to throw away seven years of work.
There is no need to build everything from scratch.
Sometimes the biggest problem is not the technology.
It is the lack of a map.
The system should outlive the people who created it
That is probably the most important rule: a good system should be able to survive the departure of a developer.
It should survive an administrator change.
It should survive a change of software house.
It should survive a company reorganization.
It should survive several years of development.
This does not mean that every programmer must understand every line of code. It means that knowledge critical to the business’s operation cannot exist only in the head of one person.
Because an employee may leave.
A freelancer may end the cooperation.
An agency may disappear.
A vendor may change the service.
And the company still has to keep operating.
Technology should be owned by the organization, not by the memory of one person
This is especially important in the case of systems built over many years.
If a company pays for software, it should know not only where the code is located.
It should know:
- what it owns,
- what it depends on,
- who has access,
- who can change it,
- how it can be deployed,
- how it can be restored,
- how it can be handed over to another team.
In its current supplier due diligence materials, NIST highlights, among other things, origin, resilience, cybersecurity practices, and supply chain dependencies. This shows a broader direction: organizations increasingly need to know not only who delivered the system, but also what the system consists of and what risks are associated with maintaining it.
This is no longer just an IT department issue.
It is a business risk management issue.
The worst time to get to know your system is during an outage
You can spend a few days on an audit.
You can organize the documentation.
You can check dependencies.
You can describe the architecture.
You can verify access rights.
You can determine who is really responsible for individual areas.
You can reduce the bus factor.
Or you can wait.
Until the system stops working.
Then the questions will be exactly the same.
Only the pressure will be greater, users will be waiting, sales may come to a halt, and every hour will cost money.
That is why it is worth asking yourself one question before a problem appears: If the person who knows your system best disappeared tomorrow, would we still know how to maintain it?
If the answer is "no," that does not yet mean the system is bad.
It means the company has a hidden risk that it has not had to activate until now.
At Web24, we take over not only the code
Taking over an existing project is a completely different job than starting a new system from scratch.
First, you need to understand what already exists.
What works.
What is critical.
What is a dependency.
What is a problem.
What is only a remnant of earlier decisions.
And above all - where the knowledge is that is necessary for the system to be safely developed.
Only then can further steps be planned.
Sometimes it will be modernization.
Sometimes development.
Sometimes organizing the infrastructure.
Sometimes taking over maintenance.
And sometimes simply creating a proper system map that no one has had time to prepare for years.
Because a responsible software house should not build technology that works only when the right person is sitting at the computer.
The system should be bigger than one person's memory.
And the business should be certain that when someone leaves, the technology does not leave with them.
