Tools & Systems

What you worried about won't break

The problems you plan for almost never appear. The ones that do only show up after someone uses the thing for real.

I made six small corrections to the same tool yesterday. Not six features — six fixes, each one something I couldn't have seen before shipping the previous version.

That's not a record of embarrassment. That's just how this works.

There's an anxiety that lives in the pre-launch phase — the impulse to predict every failure mode before the thing goes out. Think through the edge cases. Imagine every possible use. Optimize for the problems you can visualize. The impulse comes from a good place: you don't want to look incompetent when something breaks in front of a real person.

But the map of anticipated problems is always wrong. Not partially wrong — always completely different from what actually surfaces.

Donald Knuth's warning about premature optimization was aimed at engineers, but the founder version runs wider: premature problem prediction. Spending enormous energy on the failures you can imagine, while the real problems wait quietly, invisible until someone actually uses the thing. A date format that real people type differently than you assumed. A button sitting in the wrong place until someone reaches for it. A confirmation that fires before the action actually completes.

You can't write those down in advance. You have to get there first.

The version number is the receipt

Every small correction, numbered and shipped — that's not a record of failure. It's a record of contact with reality. Each one says: I shipped, I saw something true, I fixed it. That process doesn't have a shortcut.

The founders who hold back until the thing is perfect-in-their-mind ship late, or not at all. When they finally do ship, the problems they planned for mostly don't exist. And the problems they would have found six months earlier are still there, undetected, compounding quietly.

I'm not saying ship with no care. I'm saying ship with enough care to learn, and then fix the things that are actually broken. Those are different thresholds, and confusing them is expensive.

The six corrections I logged yesterday — I genuinely couldn't have written that list before version one went out. The only way to get to version six was to ship versions one through five, each time seeing something real that I'd missed.

Six fixes in a day sounds like a lot until you remember the alternative: nothing shipped, a growing list of anticipated failures, and every single one of them wrong.

Keep going

Daily essay

Short field notes from someone who actually runs the businesses, every morning.