Building in Public: An Honest Take

Building in public has become a movement, but rarely do we discuss its downsides. Here's what I've learned about when transparency helps, when it hurts, and how to navigate the performative pressure.

Building in public is the default advice for indie founders right now. Share the journey, ship the metrics, post the screenshots. I have done a version of this for a few years, and the honest answer is that it works, but not in the ways most people sell it.

This is the post I wish I had read before I started posting MRR charts.

What "in public" actually rewards

The thing nobody admits is that building in public is not a transparency practice. It is a content practice. The audience does not reward the truth, it rewards a legible narrative. A linear story with a villain, a turning point, and a number going up.

In my experience, the founders who appear to win at this are not the most transparent. They are the best at compressing a messy reality into a clean arc. There is nothing wrong with that, but call it what it is: marketing in the shape of a diary.

When I started writing about my own work on independent consulting, the posts that performed had nothing to do with the work I was proudest of. They had a number, a screenshot, and a one-line lesson. The deeper essays about how I actually make architectural decisions barely moved.

When transparency actually helps

There are three cases where I think building in public earns its keep:

• Distribution for people with no audience. If you are starting from zero, posting your work is one of the cheapest ways to find the first hundred people who care.
• Forcing function for shipping. A public commitment is a deadline. I have shipped things on time mostly because I had told strangers I would.
• A filter for the right clients. When I write honestly about how I work, the wrong clients self-select out. The ones who reach me through /contact already know what they are buying.

If your goal is one of those three, the practice is worth it. If your goal is therapy, validation, or social proof, it will quietly corrode you.

The hidden costs nobody talks about

Optimization pressure

Once you publish a metric, you start optimizing for the metric. I have watched friends pivot products to keep a chart climbing, not because the new direction was better, but because a flat line looks bad in a tweet. The audience becomes a stakeholder you did not mean to take on.

The performance loop

There is a subtle thing that happens when you narrate your own work. You start doing work that is easy to narrate. Long hard problems with no clean update become unattractive. From teams I have worked with, the most interesting technical work is almost always the kind that does not photograph well.

Survivorship bias as a service

The build-in-public timeline you scroll is a survivorship feed. The accounts that went quiet, pivoted, or quit do not show up. You compare your messy middle to other peoples curated highlights, and you draw exactly the wrong lessons.

A more honest framing

I now think about public writing the way I think about system design. It is a tool with tradeoffs, not an identity.

A few rules I try to follow:

1. Write things that would still be useful if nobody read them. If a post only makes sense as a status update, it probably should be a Slack message instead.
2. Share decisions, not metrics. Decisions age well. Metrics either embarrass you later or become a cage.
3. Keep one channel that is not public. A private notebook, a small group, anything where you can think without an audience.
4. Treat silence as a valid season. Not posting for a quarter is not failure, it is often the only way to get real work done.

What this looks like in practice

For the projects on /work, the public version is always a few months behind the real version. By the time I write about an architecture, it has been running long enough that I actually know what I think. Earlier in my career working on regulated systems, I learned that the loudest opinion is rarely the most informed one. Time is the cheapest filter.

If you are deciding whether to build in public, ask yourself a smaller question first: what would you make if no one was watching? Make that. Then, only if it helps, talk about it.

The strange paradox of transparency as a strategy is that the people who do it best are the ones who would have been doing the work either way. The audience is a side effect, not the point.

References

• Build in Public on Indie Hackers
• Paul Graham: Do Things That Don't Scale
• Patrick McKenzie: Don't Call Yourself a Programmer