There is a particular kind of anxiety that comes with showing unfinished work. The instinct is to wait — to polish, to perfect, to make it worthy before anyone sees it. But waiting is its own form of failure.
I have been thinking about what it means to build something in public. Not in the performative sense — the daily updates and growth metrics — but in the quieter sense of making your process visible. Letting the scaffolding show.
The myth of the finished thing
Most things we admire were never truly finished. They were shipped. There is a difference. Finished implies a terminal state, a point at which no more improvement is possible or needed. Shipped just means it left the building.
The products, essays, and tools we return to again and again are the ones that kept going after they shipped. They accumulated character through iteration. The first version is rarely the version anyone remembers.
The best time to publish something is when it scares you a little. If it doesn’t scare you, it probably isn’t saying anything.
This applies to code as much as writing. A function that “works” but hasn’t been read by anyone else is a hypothesis, not a fact. It works under the conditions you tested, in the context you imagined. Real work is stress-tested by the world.
What you learn by shipping early
Shipping early forces clarity. When you know someone else will read your code — or your words — you make different choices. You name things more carefully. You cut the parts that don’t carry weight. You ask yourself whether this is actually what you meant.
There are three things I have consistently learned from showing work early:
- The parts I was most anxious about were rarely the parts people noticed. The rough edges I’d agonised over were invisible to others. What they noticed was the thing I’d barely thought about.
- Feedback arrives faster than intuition. I can iterate in my head for weeks, or I can ship something imperfect and have real signal by Friday.
- The bar I set for “ready” was always too high. Not because quality doesn’t matter, but because I was setting the bar for a version that would never need to change, and that version doesn’t exist.
On the fear
The fear is real. Putting work out is an act of exposure. But I have found that the fear of showing work is almost always larger than the consequence of showing it. The version of events I imagined — where someone finds the flaw, where I am exposed as not knowing what I’m doing — rarely happens.
What actually happens is quieter and more useful. Someone finds a bug. Someone has a better idea. Someone says this is exactly what I needed, and they mean it about a version you considered throwing away.
Building in the open is not about bravery. It is about recognising that the loop between making and feedback is the actual work. Keeping that loop closed — keeping work private until it’s “done” — doesn’t protect the work. It just slows the loop down.
Ship the imperfect thing. See what it teaches you.