A Software Firm That Rests on One Person Cannot Say Who Holds What. Four Ways Forward, Weighed.

The product’s web address is due for renewal. The reminder went to an email address nobody recognises.

It takes a morning to work out whose it is. An early engineer registered the address eight years ago, in their own name, with their own card, because there was no company card yet. They still work at the firm, and they fix it in five minutes.

Then the founder asks what else is like that. The engineer thinks. The service that sends the product’s emails. The account that holds the code. Perhaps the certificate. They are not sure. Nobody has ever made a list.

What We Found

For this article we went through the public record on what a software product runs on beyond its own code: one news report of a security event at a small Indian start-up, and one survey of IT professionals on the challenges of old systems.

Three findings stand out.

A product runs on accounts, and the accounts decide whether it works. A small Indian grocery delivery start-up, with a small team, was attacked in mid-2025. By a news report, 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. The firm lost its app code and its servers. It had tens of thousands of customers. At the time of the report its app stayed up but could not take orders.

The record does not say how it happened, and neither do we. The same report says it is unclear how the attack happened. It does not say who did it, and it does not say whether anything was recovered. We did not examine why the accounts could be reached, and we draw no cause from it and say nothing about any person. The point we take is narrow: a product’s code and servers sit in accounts, and a firm needs to know what those accounts are and who holds them. This start-up delivers groceries; it does not sell software to other firms. It is in this article because its app was its product.

Security is the worry most often named. In one survey of about 500 IT professionals in the US, run by a firm that sells software services and covering every sector, more than four in ten named security weaknesses among the top challenges of their old systems, more than any other challenge. The survey is not about software firms.

Our reading is that most software firms could not say, today, everything their product runs on and in whose name each thing is held. Not because anyone hid it, but because the accounts were opened one at a time, by whoever was there, and nobody was ever asked to keep the list.

What a Firm Cannot Do While It Rests on One Person

While the knowledge of the product and the accounts it runs on rest with one person, there are things the firm cannot do, even on a quiet day.

It cannot let that person take a real break. Each account in their name, and each part of the product only they understand, is a reason to keep a phone on.

It cannot answer a plain question from outside. An investor, a buyer of the firm or a large customer may ask what the firm holds in its own name and who can reach it. Today the answer begins with “let me check with” one person, and ends with “we think”.

It cannot run its own joining and leaving steps properly. A leaving checklist that says “hand over accounts” has nothing to check against, so it cannot be completed with confidence, however willing the person leaving is.

This is our reading of the evidence. It is not a measured market figure, and it is not legal or security advice.

Four Ways Forward for a Firm That Rests on One Person, 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 firm is small, the person is content, and nobody outside is asking	Leave stays hard to take, and a question about who holds what still waits for one person
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, and the newcomer still learns by asking the same busy person; no list exists for either of them
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 still here and willing, and the firm wants to see the whole before deciding	It takes some of the person’s time at the start, the list will have gaps, and every action it leads to is the firm’s own
Commission a full security review of accounts and access	The firm’s main 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; it needs a security firm, and IOanyT does not offer it

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
Outside services the product runs on	Known from memory, in part	Every service the product’s code calls on, listed with what it does for the product	The list, taken from the assessment’s map
In whose name each service is held	Not recorded	Recorded for each, as your own people tell us, “nobody knows” included	The list
Services held in a person’s name or paid on a personal card	Not counted	Counted, each with a decision recorded by the firm	The list, set beside your own finance records
The answer to an investor or buyer who asks what the firm holds	”Let me check with” one person	A page the firm can show	The list and the specification
What the product does	In one head	Written down, checked by the person who knows it	The specification

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, what it runs on and who holds what. 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 the map also lists each outside service the code calls on, so that your own people can say in whose name each is held. 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. Acting on the list of who holds what is not part of what we build; that stays with your firm and its advisers. 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, change them or decide who should have access to what; your firm does. A list of who holds what does not make any account secure, and it will be incomplete where the code does not mention a service and nobody remembers it. We do not carry out a security review. We give no legal or employment advice, including on accounts held in a person’s name. We do not back up or recover data or code. 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 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	The founder knows what the firm holds in its own name and what it does not, before the day it matters.
CTO or CIO	One list of every service the product needs in order to run, what each does and who holds it, which the firm’s own team can work through.
CFO	What the firm pays for and what it holds are set side by side, so a service on one person’s card or in one person’s name is seen.
Head of operations	When something stops, operations knows which service it is and who is able to sign in and deal with it.
Head of people	The firm’s own joining and leaving steps can work from a real list of what a person holds, in place of a guess.

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

The case	What IOanyT does
A small Indian grocery delivery 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. The report says it is unclear how the attack happened.	Our part is far narrower, and it is not security work. We do not manage, recover or secure accounts, and we do not say our work would have changed what happened. From the assessment’s map we list what a product runs on, so that a firm can record in whose name each thing is held and act on it itself, with its own advisers.

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

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →