On Building in Public Without Performing

There’s a genre of tweet that goes something like: “Shipped this in a weekend — here’s the stack, the numbers, and a thread.” I used to write those. I liked the validation, the retweets, the sense that the work existed because other people could see it.

Then I noticed something uncomfortable. I was choosing problems based on how they would read as a thread. The features I built were the ones with the best screenshot. The writing I did was the writing that fit an arc: struggle, breakthrough, number, punchline.

Building in public had quietly become performing in public.

The performative drift

It’s not that sharing is bad. Sharing is how we learn, how junior engineers find mentors, how a small product finds its first hundred users. The problem is the feedback loop. Every like is a little hit of evidence that you’re doing the right thing — and the human brain optimizes for hits.

Within a few months, the loop reassigns the goal. The goal stops being build something useful and becomes publish something that performs well. Those two goals diverge faster than you’d expect. The work that gets attention is rarely the work that matters, because attention rewards novelty and clarity, while important work is usually slow and ambiguous.

What I do instead

I still build in public. I just changed the terms:

1. The artifact comes first, always. Code, writing, or whatever it is — it has to be complete on its own. If it wouldn’t be worth doing alone on a desert island, it doesn’t get the spotlight because of an audience.
2. I share the process, not the persona. Logs, notebooks, discarded approaches, real numbers — not narrative arcs. The value is in the detail other people can steal.
3. I never schedule the outcome. Nobody needs to know when I’ll ship. The audience doesn’t set the calendar; the work does.

The test is simple: if the audience vanished tomorrow, would I still be doing this? If the answer is yes, sharing is honest. If the answer is hedged, the sharing is the product, and I should probably just start a newsletter about sharing.

The audience is a collaborator, not a client

The best thing building in public has given me is not reach. It’s the corrections. The person who points out the edge case I missed. The stranger whose email describes the same bug they hit, three months earlier, saving me the same mistake.

Those people aren’t an audience. They’re collaborators I haven’t met yet. The distinction matters, because you owe collaborators the truth about the work — the messy middle included. You owe an audience a performance.

Build for the collaborators. Let the performance take care of itself.