One Person Knows How the Product Works. What the Firm Lacks Is a Record That Person Has Checked.

The leave request is for three weeks in December. It is the first real break the engineer has asked for in four years.

The founder approves it at once, and means it. Then the founder walks round the office. Support asks who will explain the billing run if it fails. Sales asks who will tell the new customer how the import works. The two newer engineers ask who will review their changes.

The answer to all three is the person going on leave. By the afternoon someone has suggested, kindly, that perhaps the engineer could keep a phone on.

What We Found

For this article we went through the public record on how much of a software product can rest on a few people: one small product firm’s own account in a vendor’s case study, one survey of senior leaders on finding skills, one survey of IT professionals on old systems, and one engineer’s account of documents drafted by AI tools.

Four findings stand out.

Large products are carried by small teams. One small maker of property software, in an older case from the mid-2000s, had a product of hundreds of thousands of lines of code and, in its own account, a limited development team. The account was published by a firm that sells a conversion tool, and we use only the problem it describes. It says nothing about who on that team knew what. It does show how much a few people can be carrying.

A second person is not easily found. In one survey of about 500 senior leaders at large enterprises that run mainframes, seven in ten said they had had difficulty finding the right skills. Mainframes are not our kind of work, and these are not software product firms. The point we take is narrow: a firm that plans to hire its way out of depending on one person may wait a long time.

Old systems are the ordinary state. In one survey of about 500 IT professionals in the US, run by a firm that sells software services and covering every sector, about six in ten organisations still use old systems. Old systems tend to be the ones whose knowledge has collected in a few heads. The survey is not about software firms.

A record nobody has checked can be worse than none. One engineer who works on a legacy codebase they expect to maintain for years wrote, on a developers’ forum, about documentation that teammates had produced with AI tools, that it was simply wrong, invented throughout, and that sometimes no document is better than a bad one. That is one person’s account. We read it as a reason to have every draft checked, by engineers and by the one person who knows, before anyone relies on it.

Our reading is that software firms do not rest on one person because nobody noticed. They rest on one person because writing the product down has always been a job for that same person, and that person has never had the time.

What Waits While the Product Lives in One Head

A product that lives in one head is usually discussed as a risk for the day that person leaves. Our reading is that it costs the firm something every week before that day.

The first cost is leave. The person everything rests on cannot take a real break, and the firm keeps asking, kindly, for a phone to be kept on.

The second cost is the team. Newer engineers can change only what they have been walked through. Every other part waits for one person to explain it, so work queues behind one diary.

The third is the question from outside. An investor, a buyer of the firm or a large customer asks what the product does and what records exist. The honest answer is a person’s name.

This is our reading of the evidence. It is not a measured market figure.

Four Ways to Get It Out of One Head, Weighed

There are four real options. Each one is right for somebody.

Option	When it fits	What it risks
Rely on the person, as now	The product is small, the person is content, and no buyer or investor is asking	Leave stays hard to take, and every answer about the product still has one name on it
Hire a second person to learn it from them	There is work enough for two, and the budget for it	Skills can be hard to find, and the newcomer learns by asking the same busy person
Ask the person to write it all down	The product is small and the person has time set aside	A second job for the busiest person in the firm, usually started too late
Have others read the product and draft what it does, with the person as reviewer	The product is large and old, and the person is still here and willing	It takes some of the person’s time at the start, and the record has gaps where nobody remembers

Where You Are Now, and Where You Should Be

A recommendation is only useful if you can tell later whether it worked. So before any work begins we set a benchmark: a few measures taken from your own product, each with a target.

For this issue, the benchmark would look like this.

Measure	Typical starting point	Where it should be	How it is checked
Parts of the product described in writing	Few or none	Every part described in plain words	The specification
Who has checked the description	Nobody	The person who knows the product, and your own experts, part by part	The specification, with each part marked as confirmed
Reasons recorded for rules the code does not explain	In one head	Written beside the rule they explain	The specification
Parts nobody could explain	Not known	Listed in the open, not hidden	The risk register
Questions about the product that only one person can answer	Not counted	Counted, and falling at every review	A short log kept by your own team

The starting points above are what the public record suggests and what we expect to find. In an engagement they are replaced by your own figures, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a software firm.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about your product, who it rests on and the questions that wait for one person. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. Here the system is your own product’s code and database, and the person who knows the product best is the reviewer of the specification, not its author. It produces a map of the system as it stands, a written specification of what it does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage. You get the options and our recommendation.
4. If you approve, we build. Where the assessment shows a part of the product has to be replaced, we replace a system one module at a time while the old one keeps running. We never do a single cutover. Each module has a traceability matrix. Here the build can also be an automated release process in a cloud account your firm holds, so that a release no longer rests on one person either. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
5. We review against the benchmark. Before work starts we set the benchmark. After each stage we show you where each measure stands, and the filled-in benchmark is yours at the end.

The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.

This approach has limits. We do not manage, recover, transfer or secure accounts or passwords, we do not hold your sign-in details, and we do not decide who has access to what; your firm does. A list or a written record does not make any account secure. We do not carry out a security review. We give no legal or employment advice, on leave, contracts, leaving or anything held in a person’s name. We do not back up or recover data. We do not host your product or run it. We are not a staffing firm, and we have no assistant that answers questions about your code. The record does not replace the person who knows the product, and it has gaps where the code is silent and nobody remembers. The older technologies we read include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP. We have no published case of this work for a software firm.

What changes for the business:

Role	What they gain
CEO	A holiday, an illness or a resignation no longer means nobody can say what the product does.
CTO or CIO	A written specification that the one who knows has checked, with the reasons no code records, so a second engineer can take on part of the product.
CFO	The firm’s main asset is described on paper, and can be shown when an investor, a buyer or an auditor asks what the firm has.
Head of operations	Support gets its answers from the record on the days the one person is away, and customers are not told to wait.
Head of people	The person everything rests on can take leave and hand work on, and the firm is no longer asking one employee to be always reachable.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
This article names no organisation. Its figures come from one product firm’s account in a vendor’s case study, a survey of senior leaders at large enterprises, a vendor’s survey of IT professionals and one engineer’s account on a developers’ forum.	Our assessment drafts what your product does from its own code and database, and the person who knows it checks the draft. We do not supply staff, manage or secure accounts, or carry out a security review.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. The free Reliability Review is where to start: one conversation about your product and how much of it rests on one person.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →