I shipped something yesterday that I know isn’t the best version. I could make it better. I’ll probably try to make it better for the next six weeks. But yesterday, I had to decide: is this good enough to release, or am I holding it because I haven’t learned yet?
The difference matters more than you’d think.
The two reasons you don’t ship
There are really only two things that stop you from releasing something:
The first is legitimate: The thing is broken. It doesn’t do what you said it would. There’s a real bug, a missing feature, or a hard promise you can’t keep. This is the easy one. You fix it and ship.
The second is invisible: You could ship this right now, and it would work. But you’re not sure it’s the version that should exist. You have a vision for what it could be, and the gap between what you’ve built and what you’re imagining feels like failure.
This second one is what actually slows shipping.
I spent three days last week on this exact friction. The feature works. It does what we needed it to do. But I know there’s a way to make it more elegant. I can see it. And because I can see it, shipping the thing I have in front of me feels like I’m giving up on the better version.
Here’s the trap: I don’t actually know if the elegant version is better. I know what it looks like in my head. I don’t know how it’ll feel in the hands of the people using it. And I’m holding the current thing hostage until the imagined thing is proven to be worth the extra week.
The cost of certainty about perfection
Every day you don’t ship, you’re paying for something. You’re paying with the information you’re not getting from real usage. You’re paying with the window closing on “we could build this differently if we had to.” You’re paying with your team’s confidence that things actually move.
But more importantly, you’re paying with your ability to know if the imagined version is actually better.
I’ve done this so many times. I’ve held something back for a feature that would make it cleaner. Then I’ve shipped a slightly different version six months later, and nobody asked for the thing I was trying to add. Or they asked for something completely different, and my elegant solution was now in the way.
The shipping cost isn’t measured in how good the thing is when it goes out. It’s measured in how fast you learn if you’re wrong about what matters.
What you find out by shipping
This is the thing I’m finally internalizing: shipping isn’t about declaring something finished. It’s about moving from “I think this is right” to “I know how people respond to this.”
That shift is worth more than another week of internal polish.
When you ship, people use it. They find edges you didn’t see. They use it in combinations you didn’t expect. They sometimes find that the elegant thing you were going to add was actually not what they needed at all.
This is how you learn the difference between a problem you’re solving and a problem you’re imagining.
I have friends who are architects. They design a building in their heads, they refine it for years, and then they build it. The building is usually good. But it’s also usually not what would have worked best if they’d built something simple first and then iterated. They knew too much too early.
Shipping is the opposite. You know just enough. You send it out. You learn. You iterate.
The permission you need
Here’s where the friction actually lives: you have to give yourself permission to ship something that isn’t the best version.
Not permission to ship something broken. But permission to ship something that’s good, knowing it could be better, and trusting that the improvement will come from feedback, not from more thinking.
This is hard when you can see the better version. Your brain is holding the whole shape of it. And releasing the current thing feels like admitting you were wrong about what should exist.
You weren’t wrong. You just learned more by building the first thing. The second thing will be better because you built the first one.
The rhythm I’m learning
I used to think shipping was a moment — the moment when something was “ready.” Now I think it’s a transition. The moment when you stop learning by thinking and start learning by doing.
The way to know you’re there isn’t that the thing is perfect. It’s that spending more time on it won’t answer the questions that actually matter.
“Is this elegant?” — ship it, you’ll learn if elegance mattered.
”Is this fast enough?” — ship it, you’ll learn where the bottleneck is.
”Will people understand this?” — ship it, you’ll learn where they got confused.
The questions you can’t answer until it’s in the world are the ones that matter. Everything else is you delaying your real learning by trying to be perfect in your imagination.
I shipped that thing yesterday because I realized I’d spent enough time in my own head about it. The next version will be better because I’ll know what happened when people used the first one.
That’s not settling. That’s knowing the difference between the cost of waiting and the cost of moving.
And for once, I’m moving.