// On Building in Public

For most of my career I’ve been a finisher. I don’t share things until they’re done — until the rough edges are smoothed and the embarrassing parts are hidden. It’s a habit that served me reasonably well in some contexts and badly in others. Building in public is the opposite of that instinct, and I’ve spent the last year trying to rewire myself toward it.

The practical argument for building in public is well-worn: you get feedback earlier, you stay accountable, you occasionally attract collaborators or users before you even launch. All of that is true. But the reason I actually started wasn’t strategic — it was that I had built too many things alone that never went anywhere. Keeping work private had started to feel like a way of protecting myself from the judgment that never came because nobody ever saw it.

What surprised me when I started sharing early-stage work was how little the negative reactions mattered and how much the small positive ones did. One person saying “I’ve been thinking about the same problem” is worth more to motivation than months of solo work. Not because validation is the goal, but because it makes the work feel real in a way that a private repository never does.

The thing nobody tells you is that building in public is mostly just narrating your own confusion. You share something half-baked, explain what you’re trying to figure out, and occasionally someone helps you figure it out faster. Most of the time nobody responds at all, and that’s fine too. The audience isn’t really the point. The discipline of explaining your work to an imagined reader — clearly enough that a stranger could follow it — makes the thinking better.

I still finish things before I consider them truly done. But I’ve stopped waiting for done before showing anyone. The window between “working but rough” and “ready to share” used to be months. Now it’s usually a day or two. That compression alone has been worth it.