Why I Build in Public
Sharing the messy middle beats polishing in private, but only if you share the work and not the promise. What the research says, and why AI makes it matter more.
growthBuilding in public is uncomfortable, and that is exactly why it works. You trade a little ego for a lot of momentum.
But there is a version of building in public that quietly backfires, and the research on it is surprisingly specific. Here is the trade as I see it, the trap I try to avoid, and why I think AI makes all of this matter more, not less.
The trade
- You get feedback before you have over-invested. A rough demo on stream surfaces the "wait, why would I use this?" question in week one instead of month six.
- You build an audience while you build the product. Every log, clip, and commit is a small deposit. Launch day is not a cold start.
- You stay accountable to a public cadence. It is harder to quietly abandon something people watched you start.
The cost is vanity: people see the bugs, the dead ends, and the ideas that did not work. The payoff is speed and signal. Easy trade.
The trap: announcing is not building
In 2009, psychologist Peter Gollwitzer and colleagues published a paper with a great title: When Intentions Go Public. Across four studies, people who stated an identity-related goal and had someone take notice of it then worked on that goal less hard than people whose statement went unnoticed. The researchers' explanation: being noticed gives you a premature sense that you have already become the thing you are aiming for.
That finding gets overstated online. It was about identity goals ("I'm becoming a lawyer"), not every plan you mention, and it does not settle the question for every kind of public commitment. But the mechanism rings true to me, and it explains the most common way building in public goes wrong.
"I'm going to build an AI app that does X" collects likes and congratulations for something that does not exist yet. That feels like progress. It is not. "Here is what shipped today, here is what broke" only gets attention when there is real output to point at. The applause arrives after the work, which is the right order.
So my rule is simple: show the work, don't announce the goal. I post commits, clips, screenshots, and build logs. I try not to post roadmaps.
Why AI makes this matter more
When anyone can generate a landing page, a demo video, and a polished launch thread in an afternoon, polish stops being a signal. What is scarce is proof that a real person made real decisions and stuck around to fix what broke.
The developer data shows the same tension. In Stack Overflow's 2025 Developer Survey of about 49,000 developers, 84% said they use or plan to use AI tools, up from 76% the year before. In the same survey, 46% said they do not trust the accuracy of AI output, up from 31%.
Read those two numbers together. Everyone is using AI, and fewer people trust what it produces. In that world, a public build log is a trust mechanism. It shows the prompts that worked and the ones that did not, the bug the agent introduced and how I caught it, and the judgment calls a model cannot make for you. That is much harder to fake than a finished product.
What building in public looks like for me
- Stream the build, not the highlight reel. The boring parts are where people learn the most.
- Ship small and often. A daily commit beats a quarterly reveal.
- Write down the failures. The posts about what broke are consistently more useful than the ones about what worked.
- Show the AI's work honestly. When an agent wrote most of a feature, I say so, and I show what I had to fix.
The real payoff
The best part of building in public is not the audience. It is that the work gets better. Someone in chat spots the edge case. A reader suggests the simpler design. A stranger tells me the feature I was proud of solves a problem nobody has.
You cannot get that feedback on a promise. You can only get it on something real.
Sources
Share this note
Share on X (opens in a new tab)
