The quiet cost of good-enough systems

There is a particular kind of debt that does not appear on any balance sheet. It accumulates quietly in the seams of a business — in the spreadsheet a single analyst maintains, the integration that runs on a forgotten laptop, the password kept alive in a colleague's memory. Every firm I have worked with carries some version of it, and most do not realize how heavy it has become until someone tries to lift it.

The Tuesday afternoon problem

Architecture is rarely designed. It accretes. A founder picks a CRM because their last company used it. An ops lead bolts on a billing tool because the existing one cannot handle a single edge case. Two years later the company is running on twelve systems no one chose deliberately, and the cost of changing any of them has become genuinely terrifying.

The reflex is to rip it all out. The discipline is to notice which pieces are actually load-bearing and which are simply loud. Most "obvious" rewrites are vanity projects in disguise — the system was fine, the owner was tired.

What to leave alone

If a tool is boring, well-understood, and no one is complaining, it is doing its job. Boring is a feature. The temptation to modernize for its own sake is one of the most expensive habits a technology function can develop, and it almost always trades a known set of trade-offs for an unknown one.

The work, then, is largely a work of attention. Of asking why a thing exists before deciding whether it should continue to. Of measuring not the elegance of a system but the cost of the next person who has to touch it.