Building in public
Building in public is the practice of sharing a product or company's real progress openly as it happens — including revenue numbers, failed experiments, and unresolved problems — rather than announcing only finished, polished outcomes.
The mechanism is narrative compounding. A finished launch gets one moment of attention; a build shared over months gets dozens, and each one recruits people who now have a stake in what happens next. It also produces content as a byproduct of work you were doing anyway — the deploy, the churned customer, the pricing change — which is why builders who post in public rarely run out of material while marketers writing about the same product do. Specific numbers do most of the work here, because they are the part nobody else can copy.
The tradeoffs are real and usually undersold. Competitive exposure is the obvious one: you are handing rivals your roadmap, your pricing experiments, and your churn reasons for free. In practice this matters less for early products than founders fear and more for late ones than they admit. The subtler cost is performance pressure. Once an audience expects updates, there is a pull toward shipping things that make good posts instead of things that make a good product, and toward framing every setback as a lesson. That is where building in public quietly turns into performing in public.
The honest version has a boundary: share outcomes and reasoning, withhold anything that materially damages you if a competitor reads it tomorrow — unreleased positioning, specific acquisition channels that still have headroom, customer identities. And keep the failures in. A feed of only wins is not building in public; it is a press release published in installments.
Frequently asked questions
What does building in public actually mean?
What are the downsides of building in public?
Should I share my revenue when building in public?
Devlog to Post — Turn commits and changelogs into a build-in-public update people read. Open the free tool →