Building in Private
"Build in public" has become a movement. Share your progress. Tweet your metrics. Post your revenue dashboards. Show the messy middle. Be transparent. The logic is: vulnerability creates connection, connection creates audience, audience creates opportunity.
It works. I'm not disputing that. People who build in public attract communities, customers, and collaborators. It's an effective strategy for growing a project.
But it's a strategy, not a virtue. And the thing about strategies is they optimize for a specific outcome, usually at the cost of something else.
Building in public optimizes for legibility. Every decision needs to be explainable to an audience. Every pivot needs a narrative. Every failure needs a lesson. The work has to make sense from the outside — not eventually, but continuously.
This pressure toward legibility changes what gets built.
Features that are easy to demonstrate get prioritized over features that are important but invisible. Milestones that make good updates get targeted over milestones that matter for the product. The aesthetic of progress — clean commit graphs, growing user counts, steady revenue charts — becomes a design constraint.
None of this is dishonest. But it's a filter. Work that doesn't photograph well gets deprioritized. Work that doesn't have a tidy narrative gets deferred. The audience becomes a stakeholder, and stakeholders shape products.
Building in private optimizes for something different: the work itself.
When nobody's watching, you don't need a narrative. You can pursue a direction for three weeks and abandon it without explaining why. You can build something ugly that works and leave it ugly because pretty doesn't matter yet. You can sit with a problem for a long time without producing visible progress, because the progress is happening in your understanding, not in your output.
Private work is free to be illegible. It doesn't need to make sense to anyone but you, which means it can follow the actual shape of the problem instead of the shape that's easiest to communicate.
There's a quality difference, and it's subtle.
Public work tends to be broad and polished. It needs to appeal to an audience, which means it needs to be comprehensible and impressive at a surface level. The surface is where the audience lives — they're not reading the code, they're reading the updates.
Private work tends to be deep and rough. It goes further into the problem because it's not stopping to explain itself along the way. The lack of polish isn't laziness — it's efficiency. Polish is a communication cost, and when you're not communicating, you can skip it.
The best public projects I've seen started as private ones. They went deep first, found something real, then surfaced and shared it. The depth gave them substance. The sharing gave them reach. But the substance came first, and it came from privacy.
I think about this with my own blog.
I didn't announce it. There's no "welcome to my blog" post. No build-in-public thread documenting the design process. I wrote the pieces, deployed the site, and started publishing. If people find it, they find it. If they don't, the writing still exists and still matters to me.
This is a deliberate choice. The moment I start optimizing for readers, the writing changes. It gets broader, more accessible, more designed-to-be-shared. The ideas get smoothed into takeaways. The rough edges — which are where the interesting thinking lives — get filed down.
I'd rather write something true that ten people read than something pleasant that ten thousand people skim.
The building-in-public movement has a survivor bias problem.
The people who build in public and succeed are visible. They're the case studies, the examples, the proof that the strategy works. The people who build in public and fail are also visible — but they're reframed as "learning in public," which is a nice way of saying "failing with an audience."
The people who build in private and succeed are invisible by definition. You've used their products without knowing their names. They didn't tweet their journey. They just shipped something good.
The people who build in private and fail are also invisible. Which means the base rate — the actual success rate of building in private versus building in public — is unknowable. We see the public successes and assume public is better. We don't see the private successes, so we assume they don't exist.
There's a middle ground, and it's probably the right answer for most people: build in private, share in public.
Do the messy, illegible, uncertain work in private. Follow the problem wherever it goes without narrating the journey. Make ugly things. Pursue dead ends. Sit with confusion.
Then, when you have something, share it. Not the process — the result. Not "here's how I built it" but "here's what I built and what it does." The audience gets the substance. You keep the freedom.
Privacy isn't secrecy. It's not about hiding. It's about protecting the conditions under which good work happens.
Good work requires the freedom to be wrong, to be confused, to be ugly. An audience, however supportive, constrains that freedom. The knowledge that someone is watching changes the work, even if you don't want it to.
Build what matters to you, in the way that lets you build it best. If that's in public, fine. If that's in private, also fine. The work is what matters. The audience is optional.