Must read stuff · No. 02
The locksmith's drawer and the software we can't open
A locksmith's wall of labeled drawers taught me the difference between a tool that fails and a tool that cannot be recovered. We have made our systems more reliable and less repairable, and the person at the front desk is paying for it. The drawer is not nostalgia. It is a record of who can open the thing when it breaks, and that record is disappearing from the room.
The locksmith’s shop smells of graphite and cutting oil. He sets a brass blank into the key machine, and the cutter whines through it in one slow pass, throwing a curl of metal onto the tray. He picks up the finished key, runs his thumb along the teeth, and drops it into a coffee can labeled with a client’s name in marker.
Behind him, a wall of small drawers holds springs, pins, and wafers. Each drawer has a label in the same handwriting. I ask what happens when a lock fails, and he says, without looking up, “I open the drawer and I change the pin.”
I had come because the lock on my building’s bike room had jammed again, and the committee had voted to replace it with something smarter. The locksmith listened, then took a brass cylinder from the shelf, turned it in his hand, and said the new one would work fine until it didn’t. Then no one in the building would be able to open it, and the company that made it would send a man from another city. He said this without judgment. He was describing weather.
The mechanism on the wall
What stayed with me was not the key. It was the drawers. The locksmith had a wall of labeled parts, so he could open any lock he had installed, see why it had failed, and replace one piece. His knowledge was not only in his head. It was in the labels, the coffee cans, the shelf of old cylinders. The system was built to be repaired by the person closest to it.
I thought about the software I had spent the week supporting. A dental practice I work with had a scheduling system that stopped syncing with the patient portal. The front desk called the vendor. The vendor ran a script. The script worked. The portal synced. No one at the practice learned what had happened. The next time it breaks, they will call again. The knowledge did not come back to the room.
That is the quiet mechanism of sealed systems. They are built to be reliable, and they often are. They are also built so that failures go to the original vendor. This is not a conspiracy. It is an economy of scale. The vendor knows the system. The practice knows the patients and the room. When something breaks, the vendor fixes the system, and the practice waits. The leverage, and the memory of what went wrong, moves away from the person who is actually there.
The good part, honestly
I have recommended sealed systems. I have told owners not to poke around in the admin panel, and I was right, because the alternative was a half-understood change at 4:50 on a Friday. The value of not being able to open the box is real. A six-person dental practice should not spend a day learning to service its own scheduling database. That is not resilience. It is a waste of a day. The vendor’s economies of scale are genuine. The software is steadier than what most small businesses could build or maintain themselves.
The problem is that reliability and repairability are not the same thing, and we have quietly traded one for the other. The trade is worth it for many tools. But it carries a cost that does not appear on the invoice. The front desk no longer knows why the portal broke. The locksmith’s drawers are empty in the software world. There is no local memory of how the thing works.
I saw this clearly with a studio client who replaced a booking system not because it broke but because it could not be serviced locally. The new system was better in every measurable way. It was also a black box. When it failed, the studio waited. The owner told me she missed the old system, not because it was good, but because she knew who to call, and that person knew her room.
The strongest argument against me
A friend who runs a clinic put it plainly: “You want me to learn to fix the scheduling software? I want to see patients.” She is right. Demanding repairability can be a way of dressing up overwork as virtue. Not every tool needs to be a project. The vendor’s script is faster, cheaper, and more reliable than anything she could do herself. The sealed system is not a failure of competence. It is a division of labor that mostly works.
But there is a difference between choosing not to repair something and being unable to. The clinic chooses to call the vendor. The locksmith chooses to open the drawer. The locksmith has the option. The clinic does not. When the vendor raises its prices, retires the product, or goes under, the clinic has no fallback. The drawer is empty.
What the shelf is for
The locksmith finished my key and dropped it into a coffee can with the name of my building on it. He said the smart lock would probably be fine, but he kept the old cylinder on a shelf. I asked why. He said, “Because someone will need it.”
I keep coming back to that shelf. When I choose a tool for a small business now, I ask a different question: if this breaks, who opens the drawer? If the answer is no one in the building, I want to know what we are keeping, and who will know our name when the screen goes quiet.
The bike room lock was replaced. It works. I have a key. But I also have the locksmith’s card, and on the back he wrote the name of the pin he would change if it ever jammed. I keep it in my wallet, next to the key. It is a small thing. It is the difference between a tool and a subscription.
#Essay #repair #smallbusiness #software #small business software #resilience #subscriptions #competence