Notes on Building in Public

processthoughts

Thoughts on the practice of shipping early, writing about the process, and why the seam is more interesting than the finish.

Placeholder

There’s a specific kind of terror in showing someone an unfinished thing. Particularly when that thing is software.

Software in development looks broken because it is broken. That’s the point. The process of building is a process of controlled failure — you make a thing that doesn’t work, figure out why, and make it a little less broken. Repeat until it works.

The Value of the Seam

What gets lost when you only show finished work is the seam — the place where the decision was made. Why is this component structured this way? Why did you choose this data model? The finished product gives no answer.

Building in public means narrating the decisions at the moment they’re made. That narration is valuable both to people watching and, unexpectedly, to yourself. Articulating a decision is a form of evaluating it. Trying to explain why you made a choice forces you to actually have a reason.

The Accountability Problem

The counter-argument is accountability. If you say “I’m building X,” you’ve committed to X. What if X turns out to be wrong and Y is actually better? Public commitment can make pivoting feel like failure.

I’ve found the opposite is true. The more granular your public updates, the more freedom you have to change direction. “I changed my mind about the data model” is an interesting update. It’s only a failure if you framed it as “I have built a data model” rather than “I’m thinking about the data model.”

Tense Matters

The difference is tense. Past tense narrates finished work. Present tense narrates process. Build in present tense.

← back to archive