What you learn only by using it

I was talking to something I built, and it cut me off mid-sentence.

Not rudely. Just mechanically. A pause threshold I'd set too short — it heard quiet, decided I was finished, and responded. I wasn't finished.

This is the kind of thing you can't know in advance. You can model it. You can guess. But the actual number — how long a silence is too long — doesn't exist until someone is in it, mid-thought, watching the thing move on without them.

There's a famous line that premature optimization is the root of all evil. I believe it. Building a perfect system before you know what anyone needs is one of the oldest ways to waste six months. Ship the working version. Get it in front of someone. Find out what's wrong.

But there's a quieter mistake on the other side of that advice. You ship, it works, and you treat "working" as the finish line.

It isn't.

The gap that only opens in use

Every time I actually use something I've built, I find things no planning session would have caught. The pause that's a half-second too short. The button that works on paper and becomes an interrogation in practice. The fix that closes one gap and quietly opens another adjacent one.

These aren't failures of design. They're the natural distance between a system imagined and a system inhabited. The model in your head is always incomplete. Use fills in the rest.

Shipping is an input, not an output. The version you put in someone's hands — even your own — is a question dressed as an answer: does this feel right, what does it break, what did I miss?

The correction loop that follows is not optimization. Optimization is making a good thing better according to some abstract metric. Correction is making a working thing honest — closing the gap between what you built and what the situation actually requires.

That gap doesn't close in planning. It doesn't close in testing. It closes in use.

The founders I see get stuck in one of two places: before they ship, waiting for perfect, or right after they ship, treating working as done. Both mistakes come from the same assumption — that the system you imagined is close enough to what the situation needs.

It rarely is.

Ship. Feel it. Correct. That's not a compromise. That's the method.