Perfect Is the Enemy of Done — and I Learned That the Hard Way

I had something that worked. It wasn't pretty. There were rough edges. A few things I wanted to clean up before anyone saw it. So I kept going.

Three weeks later I was still cleaning things up.

The feature I was going to add after launch somehow became a requirement before launch. The design that was good enough somehow needed one more pass. The thing that worked fine somehow needed to be rebuilt the right way before I could feel okay about shipping it.

Nobody asked for any of that. I did it to myself.

This is the trap I fall into more than any other. Not building the wrong thing. Not targeting the wrong person. Just refusing to ship the right thing because it isn't perfect yet. And perfect, I've had to learn over and over, is the enemy of good.

The version sitting on my machine helping nobody is not better than the imperfect version in someone's hands. It doesn't matter how clean the code is, how tight the design is, how well-thought-out the edge cases are — if it's not shipped, it doesn't exist.. The user can't tell you what's wrong with something they've never seen.

What I've noticed is that the things I agonize over before shipping almost never come up after. The rough edge I spent three days smoothing — nobody mentioned it. The flow I rebuilt from scratch because it felt slightly off — users navigated it without a second thought. The stuff that actually needed fixing was stuff I didn't even know was a problem until real people used it and showed me.

That's the thing about building in your own head. You manufacture problems. You imagine friction that isn't there. You optimize for a user experience you've never actually watched a real person have. Meanwhile the real problems — the ones that actually matter — are invisible to you until someone else finds them.

Ship it. Watch what happens. Fix what breaks..

That's not laziness. That's the actual process. The first version is a question, not an answer. You're asking the world whether this thing is useful and whether it works. You can't get that answer sitting at your desk making it prettier.

I've shipped things I wasn't proud of. Some of them became the most useful things I've built — not because they were good at launch but because real feedback made them good. I've also sat on things until they were "ready" and by the time I shipped them the moment had passed or I'd lost interest or the problem had changed.

Good enough and shipped beats perfect and sitting on your machine every single time.

Get it out. Improve it after.

Joel Bennett · Founder, 928 Builds · Tucson, AZ · 928builds.com #software build #lessons the hard way