A System Nobody Can Maintain

I keep meeting the same two situations at companies that have nothing else in common.

The first. A consultant built the team fifty workbooks, one per US state, then left. They are nearly identical. Any change means opening all fifty and editing them by hand, city by city.

The second. One person built the whole stack. CRM, enrichment, documents, exports. Then he went on leave. His colleague could see that data had stopped flowing. She could not tell you why and she could not fix it.

Neither of these is a bad build. Both of them run. That is what makes them hard to argue with.

They are just systems nobody can maintain.

Why that is worse than a bad system

A bad system fails loudly. Somebody notices, somebody fixes it.

A system nobody can maintain fails quietly. Data stops flowing. Nobody knows for two weeks. When someone finally looks, they find something they are afraid to touch, so they build a workaround next to it.

Now there are two systems. Both fragile. Neither written down.

Then it happens again.

I have watched this go three layers deep. Every layer was somebody solving a real problem in a hurry.

The tell

You can spot it without opening anything.

Ask the team: if we wanted to change one thing in here, who do we ask?

If everyone says the same name, you already know. The system is that person. The software is where they keep it.

That is not a criticism of the person. Usually they built something good under time pressure and nobody ever asked them to write it down.

Two questions before you build anything

I ask these before I start now. I did not always.

How much will this take to maintain?
How much will this help the company grow?

If the second answer is big and the first is small, build it. If the first answer is big, say that out loud before anyone commits, not after.

Custom things are usually more expensive than buying something. That is fine when it fits your process and it is easy to use. It stops being fine when it needs one specific human to stay alive.

What good handover actually looks like

Not a document. Documents get written once and then rot.

Here is what I have found transfers.

One place to change one thing. If a common change means editing more than one place, fix that before you hand anything over. That is the whole fifty-workbook problem, and it is a design choice, not bad luck.

Names that say what they do. A table called "Table 7 copy final" is a small landmine. Renaming things is boring and it is most of the job.

A short readme in plain words. What this does. What it costs. What breaks first. Where the keys live. Half a page beats thirty pages nobody opens.

A test somebody else can run. One row through the whole thing with a known right answer. If it comes out right, the system is alive. That gives a non-builder a way to check without understanding the internals.

A real change, made by the other person, while the builder watches. This is the one that matters. Not a demo. Not a recorded video. They make an actual change and push it. Whatever they get stuck on is exactly what the readme was missing.

Pick your most important system. On paper, make the person who built it unavailable for two weeks, starting now. Then ask somebody else to make one small change. Whatever goes wrong in the next hour is your handover gap. Much cheaper to find it this way than during someone's actual leave.

The honest part

I build things for people, so I am aware this argument works against me.

If I hand back something only I can change, I have a client forever. That is a business model and plenty of people run it.

I would rather build the smaller thing the team can own. Partly because it is the right call. Mostly because I have now seen the other version enough times to know how it ends. Somebody leaves, and the whole thing quietly becomes nobody's job.

Being maintainable is not a nice-to-have you add at the end. It is most of what you are buying.