Your system works great. As long as the person who knows why is still around.
The company has a system that was developed over seven years. It works. It serves customers. It connects to other systems. It executes processes without which the company could not really operate normally.
Over those seven years five developers worked on the project. Plus two freelancers and one agency. Some documentation is in Confluence, some on Google Drive, some in tickets. Somewhere there is an old document about one of the integrations. And when someone asks why a specific part of the system works the way it does, the answer is: "I think Michał remembered that."
Michał left three years ago.
And that is when the real problem begins.
Not because the system is poorly written. Not because it suddenly stopped working. The problem is that the company ceased to have complete knowledge about its own system.
The system works, but the company may not control it
This is one of the most underrated forms of technical debt.
When we talk about technical debt, we usually think of old code, outdated libraries, architectural mistakes, lack of tests, or solutions that were once fast but now hinder development.
Yet there is another type of debt. Knowledge debt.
It arises when a system depends on information that is not in documentation, repositories, procedures, or the organization, but only in the heads of specific people.
And as long as those people are available, everything may appear normal.
The problem appears when the team changes, a developer leaves, cooperation with a software house ends, a server fails, an administrator changes, or there is a need to quickly deploy a new solution.
Suddenly it turns out the company has the code but not the knowledge.
It has the server but not the certainty of who has access.
It has an integration but doesn't know which account it was created under.
It has documentation but doesn't know which version is up to date.
It has a process but doesn't know why it was designed that way.
And then a question quickly emerges: who actually owns this system?
Bus factor — what happens if one person disappears?
In the IT world there is the concept of the bus factor. Simplified, it means the number of people whose absence would cause a team to be unable to effectively develop or maintain a project.
It is not about a literal event. It's a way of thinking about knowledge concentration.
If only one person knows how a critical integration works, the bus factor for that knowledge is one.
If only one administrator has production access, the bus factor is one.
If only one person knows why the system runs a certain process every night, the bus factor may be one.
If the company cooperates with an external software house and no one on the client side understands the solution's architecture, an even bigger problem arises — the knowledge may reside outside the organization.
This does not mean every company must have five experts for each part of the system.
It is something much simpler: the company should know where critical knowledge is and whether it can recover it without a specific person.
Code tells how. Not always why.
A developer can read the code and understand what a function does.
They will not always know, however, why it was written in that particular way.
That's a huge difference.
You can find the fragment responsible for sending data to an external system. You can analyze the endpoint, parameters, authorization and error handling.
But the code won't necessarily answer questions like:
- Why do we send the data at 2:00 a.m.?
- Why is this particular status skipped?
- Why does the system retry exactly three times after an error?
- Why is one value transformed before sending?
- Why can't the order of these operations be changed?
- Why does this integration use a specific account?
The answer may be in the project's history, an old ticket, an email from six years ago or — worse — only in the memory of someone who no longer works at the company.
Therefore good documentation should not be only a "what to click" manual.
It should also store context and decisions.
The biggest problem may be an integration that no one remembers
A modern system almost never works completely on its own.
It connects to ERP. CRM. A payment gateway. An SMS provider. A courier system. A partner API. A cloud service. An analytics platform. An accounting system. An authorization mechanism.
Each such connection is part of the technological chain.
And every part of that chain can have its own owner, account, API key, certificate, contract, quota, API version and lifecycle.
After a few years no one may remember who created a given account.
And then it is enough for a certificate to expire or an API to change for the system to stop working.
Even worse if the company does not even know that a given dependency exists.
That is why, in a mature approach to systems, software provenance, dependency management and supply-chain transparency are becoming increasingly important. NIST in its current materials on software supply chain security points to the importance of information about components, their origins, lifecycles and dependencies. SBOM, or Software Bill of Materials, is one of the tools that helps organize knowledge about what components make up the software.
This is no longer only a topic for the security team.
It is also a topic for the board.
Because if a company does not know what its system is built from, it is harder to assess risk, maintenance cost and the consequences of changes.
Documentation is not a cost. It is an insurance policy.
In many companies documentation is treated as something "to be done later."
First functionality.
Then deployment.
Then fixes.
Then the next project.
And documentation?
"When there is time."
The problem is that the time for documentation usually comes when it is already too late.
Documentation should act like business insurance. Not because someone will read it every day. On the contrary — hopefully it will be needed as rarely as possible in an emergency.
But when a problem happens, the company should be able to answer basic questions:
- How does the system work?
- What is it composed of?
- Where is the production environment?
- Who has access?
- What are the critical integrations?
- Which external accounts and services are used?
- What are the dependencies?
- How are backups performed?
- What does the deployment process look like?
- What happens during a failure?
- Which elements are critical for the business?
- Why were key architectural decisions made?
- Who can take over system maintenance?
This does not have to mean hundreds of pages of documentation.
Good documentation should primarily be useful, up to date and available to the right people.
"Don't touch it, it works" is not always the wrong decision
There is one more very common problem.
A system has worked for years, so the company adopts the principle: "Don't touch it. It works."
And sometimes that is absolutely reasonable.
Not every old technology needs immediate replacement. Not every older piece of code must be rewritten. Not every library signals disaster. Not every architecture from years ago is wrong.
The problem begins when "don't touch it" also means:
- "Don't analyze."
- "Don't document."
- "Don't check dependencies."
- "Don't ask who has access."
- "Don't verify we still have all accounts."
- "Don't determine what will happen if the current contractor becomes unavailable."
Then lack of change is not a strategy.
It is postponing risk.
Sometimes the best technical decision is indeed to not rebuild anything.
But that decision should come from knowledge about the system, not from lack of knowledge about the system.
What should an audit of an inherited system include?
When a company takes over a system from another software house, a freelancer or an internal team, the first step should not be automatically rewriting everything.
First you need to understand what exactly was taken over.
An audit should answer at least several basic areas.
Architecture. How is the system built? What are its main components? Where is the data? How do the components communicate?
Code and repositories. Does the company have the complete source code? Is it known which branch and version are production? Is the build and deployment process reproducible?
Infrastructure. Where does production run? What does the test environment look like? Who has access? What about monitoring and backup?
Integrations. What does the system communicate with? Which APIs are used? Who owns the accounts and keys?
Dependencies. What libraries, frameworks and external components are used? Are they updated? Do they have known security issues? What is their lifecycle?
Deployment process. Can a new person prepare, test and deploy a change without calling the former developer?
Knowledge. What is in documentation and what still exists only in people's heads?
Business risk. What happens if a certain component stops working for an hour, a day or a week?
The modern approach to software supply chain security increasingly emphasizes the need to know components, suppliers, dependencies, their origins and lifecycles. NIST also points to the importance of due diligence toward technology suppliers and assessing resilience and risk across the entire supply chain.
An audit does not mean "rewrite the system"
This is important because a technical audit is often mistakenly equated with a rebuild.
However an audit may end with a very simple conclusion: "The system is fine. We just need to organize the knowledge and remove a few risks."
It may also turn out that the system requires modernization in only one area.
Or that the biggest problem is not the code but lack of access to the infrastructure.
Or that the application is well written, but no one has up-to-date knowledge of the deployment process.
Or that everything works, but the company is dependent on a single external provider.
Therefore a good analysis of an inherited project should answer the question: "What really needs to be changed and what does not need touching?"
Only then can investment decisions be made.
What if you are changing software houses?
This is one of the moments when the invisible debt of knowledge becomes apparent.
The company ends cooperation with the contractor.
The new partner receives the repository.
And starts asking questions:
- "Where is production?"
- "How to run the project locally?"
- "Which version is current?"
- "What does this service do?"
- "Who owns the account for this API?"
- "What does this cron job do?"
- "Why does this process run at this time?"
- "Where does this parameter come from?"
- "What happens if we turn it off?"
If the answer to most questions is "we don't know", the new software house will not take over the project. First it has to discover it.
And discovering the system costs time. Time that the client pays for later.
That is why handing over a project between teams should be a process, not dropping a ZIP with code and a password to a single account.
The system should outlive people
This is probably the most important principle.
People change. Developers change jobs. Freelancers end cooperation. Software houses change clients. Administrators move to other companies. Boards change.
The system remains.
Therefore the system should be designed so that the knowledge needed to maintain it can be recovered.
That does not mean every employee must know everything.
It means the organization should have a mechanism for storing knowledge:
- Repositories.
- Documentation.
- An integrations register.
- Infrastructure information.
- Company-managed access.
- Descriptions of key processes.
- A history of important decisions.
- Information about dependencies.
- Emergency procedures.
- And above all — people who know how to use that documentation.
NIST in its current guidelines on systems security also draws attention to formally defining responsibilities, operational status of systems and the roles of people who manage, support or have access to them.
This shows a broader shift in thinking about technology.
A system is not just code. A system is also people, processes, infrastructure, dependencies, data, access and responsibility.
At Web24 we often start precisely with the question: "What do we actually have here?"
Taking over an existing project should not start with a promise that everything will be rewritten.
It should start with understanding the situation:
- What works?
- What doesn't work?
- What is critical?
- What is outdated?
- Where are the biggest risks?
- What is missing from the documentation?
- Which dependencies are invisible?
- Can the existing system be safely developed?
- Is modernization needed or just organization?
Only then can you decide whether the project should be developed, rebuilt, partially rewritten or simply well documented.
This is especially important for projects that over the years were developed by various people and different companies.
Because a good technology partner should not be needed because only they know how the system works.
They should be needed because they can develop the system, secure it and pass the knowledge on.
The most dangerous mistake may be the person who already left
Old code is not always the problem.
Outdated technology is not always the problem.
Lack of the latest framework is not always the problem.
Sometimes the greatest risk is information that no one wrote down.
One password.
One architectural decision.
One integration.
One exception in a process.
One person who for years knew how it worked.
And then they left.
So ask yourself a very simple question today: If the person who knows your system best disappeared from the company tomorrow, would you still be able to manage it?
If the answer is "yes" — great.
If it is "I don't know" — it's worth checking.
And if it's "definitely not" — you have probably just found one of the most important areas of technological risk in your company.
The system should be bigger than one person's memory.
