Recovering From a One-Person System: A Common Small Business Pattern

A common pattern among small and midsize businesses is depending for years on a business system — sales management, inventory, and the like — built single-handedly by the one person in the company who was 'good with IT.' It is often only when that person announces they are leaving or transferring that the company discovers no one else understands the source code or how the servers are managed.

This article is not about any specific company. It generalizes a pattern of challenges and resolutions commonly seen among small and midsize businesses. The company, figures, and episodes described are a composite typical example, not a depiction of any real, identifiable company.

Picture a wholesale/retail company with about 40 employees. More than a decade ago, an IT-savvy employee built a custom sales management system on their own initiative to improve efficiency, and has maintained and modified it single-handedly ever since. The system is now deeply embedded in daily operations — order intake and inventory management cannot run without it.

The essence of this pattern is 'one-person dependency.' Nobody besides the original builder knows where the source code lives, who holds the contracts for the server and domain, the login credentials for the admin panel, or the reasoning behind why a given piece of logic works the way it does. The moment that person announces they intend to leave, the company often realizes the scale of this risk for the first time.

It is also common for the system's accounts and server contracts to be registered under the individual's personal name or personal email, or for that person to have been personally fronting server costs. A business-critical system where the company itself was never the actual contracting party is a structural problem that shows up repeatedly in this pattern.

What makes this even trickier is that, over the years since the system was first built, day-to-day operating rules have gradually adapted to fit the system's behavior rather than the other way around. An unwritten operating playbook accumulates — 'because the system behaves this way, we handle it like this on the floor' — so understanding the code alone does not reveal how the business actually runs. Knowledge that exists only in one person's head is split across both the code and the informal operating habits of the team, which makes a clean handover much harder.

In a typical case, with only a few months left before departure, the company first lowers the immediate risk with 'keep as-is plus documentation,' while simultaneously searching for an outside maintenance vendor — a two-stage approach. If a future replacement is being considered, reading a full ordering guide and a primer on what a person-month means helps set realistic scale expectations before talking to vendors.

- Right after the resignation is confirmed: inventory the source code, server/domain contract details, and admin login credentials, and switch ownership to the company wherever possible
- Month 1: interview the departing employee and produce a lightweight system diagram and process-flow document
- Month 2: talk to candidate outside maintenance vendors, using a complete maintenance guide to define the scope of what's outsourced
- Month 3: sign the maintenance contract and hold a handover meeting with the departing employee present
- After departure: the outside vendor takes over maintenance, and replacement planning may begin in parallel if needed

Documentation and handover support typically run roughly ¥hundreds of thousands to about ¥1M, and outsourced monthly maintenance is often in the range of roughly ¥tens of thousands to low hundreds of thousands per month. A full replacement can reach several million yen, with a wide range depending on system scale and migration scope. Costs vary significantly by vendor, so getting quotes from multiple companies and comparing them is strongly advised.

Documentation and handover work in particular tends to cause disputes later if the scope is left vague when the engagement is requested. It helps to agree in advance — and put in writing — how much of the source code will be analyzed, how many interview sessions are included, and what form the deliverables will take (a system diagram, a spec document, an operations manual, and so on).

- 'Tacit specifications' known only to the original builder (why a particular condition branch exists, for example) never make it into the handover documentation before departure
- Servers, domains, and admin panels remain tied to personal accounts or personal devices and become inaccessible once the employee leaves
- The system has run for years without anyone checking the contract or basics of a development contract, leaving copyright ownership and subcontracting rights unclear
- Not enough handover time is set aside, forcing a last-minute scramble right before departure — a pattern that also shows up in common failure patterns
- A minor glitch appears after departure and there is no one left who can fix it, exposing a risk the company had overlooked: operations grinding to a complete, if temporary, halt

The 'one-person system' problem tends to stay hidden while the person who built it remains employed, then surfaces all at once as a company-wide risk the moment they leave or transfer. Once a resignation is known, treating the inventory of source code and account credentials as the top priority — and deciding how to use the limited handover window — determines how quickly the company can recover.

While a single departure is often the trigger, the deeper issue is a longer-term management question: how to keep the system running without depending on any one person. Even after the immediate handover is complete, whether the company can sustain a habit of updating documentation and keep more than one person able to touch the system is what ultimately decides whether the same problem returns.