Building in public is one of those ideas that sounds straightforwardly good until you do it for a while.
The theory is clean: share your work as you make it, get early feedback, build an audience, stay accountable. People who've done it well - levels.io, Jon Yongfook, Lenny Rachitsky - make it look like a natural extension of the work itself. It isn't.
What building in public actually costs
The thing nobody tells you is that building in public adds a production layer on top of everything you're already doing. You're not just building - you're building and reporting on what you're building, simultaneously, in a way that other people can follow and form opinions about.
That second layer is heavier than it looks. Every week you haven't shipped something becomes a week you're silent, which starts to feel like failure even when it isn't. Every decision you make in public is now a decision someone can weigh in on, which is useful sometimes and exhausting always.
And then there's the vanity metrics trap. If you're watching the numbers - followers, impressions, likes - you're optimising for something other than the product. The feedback you get is weighted toward people who spend time on social platforms, which is a specific and unrepresentative sample of your eventual users.
What it's actually useful for
None of this means building in public is a bad idea. It means the useful version of it is narrower than the popular version.
The thing building in public is genuinely good for is accountability without perfectionism. Sharing a screenshot of something half-done makes it real. It commits you to finishing it. It forces you to understand what you're building well enough to explain it to someone else. That's valuable regardless of how many people see it.
It's also useful for finding people who have the problem you're solving. Post about a specific problem and the people who recognise it will find you. These are your early users. They're more valuable than followers.
The rule I've found useful
Only share when you have something to show. Not a plan, not a goal, not a commitment - something that exists that didn't before. A feature that works. A problem you figured out. A mistake you made and what happened.
This does two things. It keeps the reporting load manageable because you're only reporting on real progress. And it keeps the content honest, because showing is harder to fake than telling.
The corollary is that silence is fine. Not every week produces something worth sharing. Pretending otherwise is where the burnout comes from - the pressure to perform building rather than actually build.
On the audience question
Everyone building in public is building an audience at the same time, whether they admit it or not. The question is whether the audience is the point or a side effect.
If the audience is the point, you will eventually start making product decisions based on what plays well, which is how you build something that gets attention and doesn't solve any problems.
If the audience is a side effect - if you're sharing because it makes the work better, not because it makes the numbers go up - then the people who stick around are the ones who actually care about what you're doing. That's a smaller number and a much more useful group.
Build the thing. Share the thing when there's something to share. The rest takes care of itself or it doesn't, and you can live with either.