The System Only One Person Can Touch

We were once asked for help with a system that had been running for four years. Functionally the owner was satisfied. What made them reach out was simple: the person who built it could no longer be reached, and one small change had to be finished that month.

This situation rarely begins with bad intentions. The system was built by one or two very capable people, and while they were around everything went smoothly. What never got built alongside it was a way for anyone else to get in.

Gradually that capability becomes a single point. Estimates depend on who happens to be available. Questions get answered by a person rather than by a note. Changes are made by trial and error because no one is sure which parts are safe to touch.

A system’s value is in how easily it can be changed

Work on a legacy system usually starts with us changing nothing. We read first, run it, and write down what actually happens, not what the folder names suggest should happen. That write-up is often the first document the system has ever had.

Once the picture exists, the next decisions get much calmer: which parts need to be secured first with tests, which parts can be left alone, and how much effort the next change genuinely takes.

Signs we usually find:

• One name appears in nearly every technical question, including simple ones.
• There is no way to run the system on another machine without asking a specific person.
• Small fixes come with the sentence “be careful, that part is fragile”.
• The previous developer’s contract and contact details are no longer active.

If we do go on to build after that, one condition holds: whatever we produce has to be continuable by someone else after we leave. That is part of the job, not a bonus at the end.

If your system is in that position (running well, but only one person dares to change it), a short assessment of its condition usually shows how large the risk is and which step is cheapest to take first.