Who Holds What

1. At a Glance

Issue study · From the public record. None of the organisations described here was an IOanyT client, and IOanyT had no part in the events described. Everything about them comes from the public record. The named case is a security event, and IOanyT’s part in that kind of problem is narrower: it is not security work.

Organisation type	Software firms whose product rests on one person: what the product does, the accounts it runs on and the steps that put it live. One public case (a grocery delivery start-up whose app was its product) and one small product firm, set beside surveys of skills and of old systems
Size band	The firms in the record: both small. Our reader: a small or mid-size software firm whose first engineer or founder still holds most of the product
Region	The start-up: India. The surveys: the US and large enterprises in general
The decision at stake	How to spread the weight that rests on one person, while that person is still here and willing, without taking anything from them
The public outcome	At the start-up, by a news report in mid-2025, attackers gained access to its main cloud and code-hosting accounts, and it lost its app code and its servers. At the time of the report its app stayed up but could not take orders. The report says it is unclear how the attack happened
Why it matters to a small or mid-size software firm	A firm that cannot say what its product runs on and in whose name each thing is held cannot let its key person rest, and cannot answer an investor’s or a buyer’s question about what it holds

2. The Business Problem, in the Buyer’s Words

“Our first engineer built the product with me eight years ago and is still here. They know why everything works as it does. Most of the accounts the product runs on were opened in their name in the first year, because there was nobody else. They release every new version from their own laptop. They have not had a proper holiday in four years, and I have stopped asking them to write things down, because they never have the time. An investor asked me last month what exactly the firm holds in its own name. I said I would come back to them. I still have not.”

These words are imagined. They describe the decision as the research shows it, not a real conversation.

The firm is not in trouble. Nothing has gone wrong. But everything rests on one willing person being there, and the firm cannot show anyone, including itself, what that person holds.

3. What We Found

Method. We went through the public record on how much of a software product can rest on one person or a few: one news report of a security event at a small Indian start-up, one small product firm’s 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.

The public case. These are the report’s own words, and we add nothing to them.

What	Public record
Organisation	A small Indian grocery delivery start-up with a small team (not named: known from one news report)
Access	Attackers gained access to its main cloud and code-hosting accounts. Logs the company shared suggested, in the report’s account, that access came through the account of someone who had left
What was lost	Its app code and its servers
When	Mid-2025
Scale	Tens of thousands of customers
At the time of the report	Its app stayed up but could not take orders
How it happened	The report says it is unclear how the attack happened. It does not say who did it, or whether anything was recovered

We did not examine why the accounts could be reached, and we draw no cause from it. We say nothing about any person. The firm delivers groceries; it does not sell software to other firms, and its app was its product. We use the case for one narrow point: a product’s code and servers sit in accounts, and a firm needs to know what those accounts are and who holds them.

A large product and a small team. 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. We use only the problem it describes, do not name the firm and use nothing of what it did next. It says nothing about who on the team knew what.

What the surveys report. These are about IT in general, not about software firms.

• 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 IOanyT’s kind of work; the figure shows only that a second person is not easily hired.
• In one survey of about 500 IT professionals in the US, run by a firm that sells software services, about six in ten organisations still use old systems. Among the top challenges, more than four in ten named security weaknesses and nearly four in ten high maintenance and support costs. Among reasons for not modernising, nearly four in ten named fear of disrupting operations.

A record nobody has checked. One engineer who works on a legacy codebase they expect to maintain for years wrote, about documentation 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, and we read it as a reason to have every draft checked before anyone relies on it.

Our reading of why a firm comes to rest on one person. These four are our reasoning from the record above. None is a finding of any source, and neither firm above is said to have come about for these reasons.

1. What the product does, and why, is in one head. It was explained by word of mouth and never written down, because the one who could write it is the one every urgent thing goes to.
2. Nobody has a list of what the product runs on. Accounts were opened as they were needed, by whoever was there, and nobody sees the whole.
3. Nobody has recorded in whose name each of those things is held. So the firm finds out one renewal or one sign-in at a time.
4. Putting a version live is a set of hand-run steps on one person’s computer. Nobody else can do it, or safely learn to.

4. The Options a Firm in This Position Had

Option	When it fits	What it risks	Our view
Rely on the person, as now	The firm is small, the person is content, and nobody outside is asking	Leave stays hard to take; a question about who holds what waits for one person	Right only as a pause with an end date
Hire a second person to share the load	There is work enough for two and the budget for it	Skills can be hard to find; the newcomer learns by asking the same busy person, and still has no list	Right later, and easier once a record and a list exist
Write the product down with that person as reviewer, and list what the product runs on and in whose name each thing is held, for the firm to act on	The product has grown for years, the person is here and willing, and the firm wants to see the whole first	Takes some of the person’s time at the start; the list has gaps; every action it leads to is the firm’s own	Our recommendation
Commission a full security review of accounts and access	The firm’s worry is who can reach its systems and whether they are protected, or a buyer asks for one	It answers whether accounts are protected, not what the product does or why	Right where the list turns up something security advisers want examined. IOanyT does not offer it

5. Our Recommendation, and the Decision It Asks of the Board

Have the product read by others and its behaviour written down in plain language, from its own code and database, with the person who knows it checking the draft and adding the reasons no code records. From the same reading, list everything the product’s code calls on, and have the firm’s own people say in whose name each is held, who pays for it and who can sign in (names only, never passwords), “nobody knows” included. Keep the list where only the people who need it can see it. The firm then decides, with its own security and legal advisers, what to put right, line by line. Where releases rest on the same person, build an automated release process in a cloud account the firm holds, from the steps that person shows, and hand it to the team.

6. Benchmark: Where You Are Now, and Where You Should Be

These are targets, not results. In an engagement the starting points are replaced by the firm’s own figures, taken in the first review.

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, checked by the person who knows it	The specification
Outside services the product runs on	Known from memory, in part	Every service the code calls on, listed with what it does	The list, taken from the assessment’s map
In whose name each service is held	Not recorded	Recorded for each, as the firm’s own people say, “nobody knows” included	The list
Services in a person’s name or on a personal card	Not counted	Counted, each with a decision recorded by the firm	The list and the firm’s own finance records
Who can make a release	One person	Any engineer the firm allows	The firm’s own record of each release
Questions only one person can answer	Not counted	Counted, and falling at every review	A short log kept by the firm

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about your product, who it rests on and what it runs on. 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 study 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; the person who knows the product best reviews the specification, and the map lists each outside service the code calls on. 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.
4. If you approve, we build. Here that can mean an automated release process, built in a cloud account your firm holds and handed to your team. Where 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. A traceability matrix links every old function to its replacement. 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.

8. What the Client Would Own

• The specification: what the product does, in plain words, checked by the person who knows it, with the reasons no code records.
• The list: everything the product’s code calls on, what each does, and in whose name each is held, as the firm’s own people said. The firm acts on it.
• The risk register: what the assessment found, including the parts nobody could explain, listed before any price is set.
• The release process: where one is built, the automated process in the firm’s own cloud account, with its instructions.
• The code and the traceability matrix: for any module IOanyT rebuilds. No runtime or platform fee.
• The filled-in benchmark: each measure, where it started and where it stands.

9. What This Approach Does Not Cover

• IOanyT does not manage, recover, transfer or secure accounts or passwords, change sign-in details or hold them, and does not decide who should have access to what. The firm does.
• A list of who holds what, a written record or an automated release does not make any account or product secure. IOanyT does not carry out a security review.
• In the public case, IOanyT’s part is narrower than the event: it is not security work, and nothing here says IOanyT’s work would have changed what happened.
• IOanyT gives no legal advice on accounts held in a person’s name, and no advice on employment, contracts, leave, leaving or who is on call.
• IOanyT does not back up or recover data or code.
• IOanyT does not host the product, run its releases or stay on call.
• IOanyT is not a staffing firm and has no assistant that answers questions about the code. The record does not replace the person who knows the product.
• The list will be incomplete where the code does not mention a service and nobody remembers it.
• The older technologies IOanyT reads include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP.
• This study does not say that IOanyT has done this work for a software firm. IOanyT has no published case of it.

About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.

10. Sources

Source	Used for
A technology news report, mid-2025	The start-up: staff, access, what was destroyed, dates, customers and orders, the state at the time of the report
A vendor’s case study	One small maker of property software
News report of a vendor’s survey, September 2025	Skills at large mainframe-based enterprises
A vendor’s survey of about 500 US IT professionals, 2025	Old systems; challenges; reasons for not modernising
Developers’ forum post, March 2026	One engineer on documents drafted by AI tools

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 who your product rests on, and what it runs on.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →