Building in Public: What 12 Months of Sharing Our Numbers Taught Us

Building in public means publishing the decisions, trade-offs, and results of your business while they're still unresolved — not after they've been polished into a case study. After twelve months of doing it, the honest summary is this: building in public is an excellent way to earn credibility and a poor way to acquire customers. It compounds trust with people who like watching a decision get made. It does not, on its own, put buyers in front of your product.

That distinction sounds small. It isn't. Almost every mistake we made in the first year came from treating building in public as a growth channel and then being disappointed when it behaved like a credibility channel instead.

This post is in two halves. First the scorecard — what sharing our numbers actually delivered, what it cost us, and what we got wrong. Then the playbook — what's worth publishing, what should stay private, how often to post, and the exact shape of an update that stays useful after the moment passes.

What does "building in public" actually mean?#

The phrase covers a wide range of behaviour, and the range is the reason people argue about whether it works.

At one end there's metric broadcasting: posting a revenue figure, a subscriber count, or a chart on a schedule. It requires no explanation and produces very little durable value, because a number without a decision attached is trivia. Nobody's situation changes because they learned your revenue on a Tuesday.

At the other end there's decision publishing: describing a choice you faced, the options you rejected, the reasoning you used, and what happened next. This is the part that keeps working. A well-written account of a pricing decision is still useful two years later, to a reader who has never heard of you, because the reasoning transfers even when the numbers don't.

Most people who say building in public "didn't work for them" were doing the first thing. Most people it did work for were doing the second. We spent our first few months in the first camp before figuring that out.

For us, the practice took four concrete forms: a written monthly retrospective on the blog, shorter decision notes when something changed mid-month, public post-mortems when we shipped something wrong, and answering "why did you do it that way?" questions in the open rather than in DMs.

Does building in public actually grow a business?#

It grows one specific thing reliably, and three things unreliably. Being clear about which is which is the whole game.

What it reliably delivered: a distribution channel that doesn't depend on an algorithm liking us.

This is the underrated part. Every other channel we have is intermediated. A search engine decides whether a page ranks. A feed decides whether a post gets shown. Building in public created a small group of people who actively check whether we've posted, because they're following a story rather than consuming a piece of content. That audience is not large. It is also not subject to a ranking change we didn't cause and can't appeal.

What it reliably delivered: faster, harsher, more useful feedback.

Publishing a decision before you know the outcome invites correction from people who've made the same decision. Several times, someone with more experience than us pointed out a flaw in reasoning we'd already committed to internally. Privately, that flaw would have surfaced months later in the form of a metric moving the wrong way. Publicly, it surfaced in a week, in a comment, from someone with no incentive to be polite about it.

The mechanism matters here: it isn't that our audience is smarter than us. It's that writing a decision down for strangers forces the reasoning to be legible, and illegible reasoning is usually bad reasoning. Half the corrections came from us, in the act of writing.

What it reliably delivered: accountability that changed what we shipped.

Having said in public that a thing was a problem makes it much harder to quietly stop caring about it. When we killed our viral score feature, the fact that we'd publicly described what it was doing to creators' decisions is a large part of why we removed it instead of tweaking it and moving on. Private conviction erodes under deadline pressure. Published conviction erodes more slowly.

What it delivered unreliably: signups.

Some, occasionally, in bursts, from a post that traveled. Never predictably. The conversion problem is structural, not fixable with a better call to action — which brings us to the costs.

What does building in public cost you?#

Four costs, in rough order of how much they hurt.

The audience mismatch#

The people who follow a build-in-public account are, overwhelmingly, other builders. They are a genuinely great audience: generous, technically literate, quick to give feedback, quick to share. They are also, for a product aimed at creators, largely not the buyer.

So you end up running a highly engaged channel populated by people who enjoy the making of the thing rather than the use of the thing. Engagement on those posts is real, and it is not demand. We conflated the two for months, and the tell was obvious in hindsight: our most-shared build posts produced our least-qualified traffic — visitors who read one page about how we made a decision and never once opened the product.

This isn't an argument against building in public. It's an argument for not counting it as an acquisition channel in your model, and for keeping a separate channel aimed at the actual buyer.

The performance tax#

Once you know you'll be writing an update, the work starts bending toward what makes a good update. Nobody decides to do this. It happens anyway, the same way any measured process drifts toward what's being measured.

It shows up in small distortions. A visible feature gets prioritised over an invisible reliability fix, because one is narratable and the other is a paragraph nobody reads. A decision gets made a week early so it can go in this month's note. A messy in-between state gets tidied into a cleaner story than the one that actually happened.

The only defence we found is a structural one: decide the month's priorities before writing anything, and treat the update as a report on that list rather than an input to it. Write from the decision log, not from memory — memory is already edited.

The exposure of a bad stretch#

Publishing during a good month is easy and mildly addictive. Publishing during a flat month, when the honest report is "we shipped less than planned, one bet didn't work, and the number moved the wrong way," is the part that makes people quietly stop.

That's exactly when it's worth the most. A record that only contains good months isn't transparency, it's marketing with a transparency aesthetic, and readers detect the pattern faster than you'd expect. The flat-month posts got us more thoughtful replies than the good-month posts did — and they're the reason the good-month posts are believable at all.

The time it takes from the product#

A monthly retrospective written properly — pulling real figures, checking claims, writing something with a point — costs the better part of a day. Decision notes cost an hour or two each. Across a year that's real product time, and pretending otherwise leads to the failure mode where updates get written at 1am and read like it.

What we got wrong in the first year#

Five mistakes, all of which we'd now warn someone else about.

We treated transparency as a launch tactic. The early posts existed to get attention. Attention-seeking transparency has a distinctive smell — it emphasises whatever number happens to be flattering this month and goes quiet when nothing is. It also can't be sustained, because the tactic runs out the moment the numbers aren't interesting.

We published metrics with no decision attached. A chart with no accompanying "and so we changed X" is content that expires the day it's posted. Roughly the first third of what we published in year one is now worthless — not wrong, just inert.

We over-narrated small wins. Announcing every small improvement inflates the register. When something genuinely significant happens later, you've spent the vocabulary and have nothing louder to say. Worse, it trains readers to skim.

We confused engagement with demand. Covered above, and the most expensive of the five, because it distorted planning for a full quarter.

We under-published the reversals. The posts where we said "we were wrong about this, here's what we think now" were consistently the most valuable, and we wrote the fewest of them — because they're uncomfortable and they take the longest. Same lesson we learned from content generally: a small fraction of posts drives most of the value, and the reversal posts were sitting in that fraction the whole time.

What should you share when building in public?#

Here's the sorting rule we settled on: share the reasoning, not the readout. A reader who learns how you decided can use it. A reader who learns what your number was can only react to it.

Two entries there deserve expanding.

Reversals are the highest-value thing you can publish. They're rare, they're specific, they can't be produced by a content mill, and they demonstrate the one thing that actually predicts whether a company is worth trusting: that it updates on evidence. If you write one thing this quarter, write the thing you changed your mind about.

Roadmap promises with dates are the most tempting mistake. They read as confidence and they function as debt. Ship-by dates in public get treated as commitments by readers and as pressure by you, and the pressure lands on quality first. Publish the problem you're working on, not the date you'll have solved it.

What numbers should you keep private?#

Privacy is not dishonesty. The useful framing is a disclosure ladder: three rungs, based on whether the number can be understood without a paragraph of context.

Rung 1 — safe to publish plainly. Numbers that mean the same thing to everyone and don't need interpreting. Pricing. Cost structure at the category level, like what a typical unit of usage costs to serve. Headcount. Cadence. Anything already visible from outside.

Rung 2 — publish only with the context that makes it honest. Numbers that mislead when isolated. Growth rates off a small base. Conversion rates without the traffic source. Retention measured over a window shorter than your billing cycle. Any figure where a reader could reasonably draw the opposite conclusion from the one the data supports. Publish these with the denominator, the window, and the caveat, or don't publish them.

Rung 3 — keep private by default. Anything that isn't only yours to share, or that materially changes someone else's position. Customer-identifying detail, obviously. Vendor terms and negotiated rates. Individual compensation. Anything under a confidentiality obligation. Anything that would give a competitor a precise map of your cost floor.

A public commitment we'd make again: state which rung you operate on. "We publish pricing and cost categories, we don't publish per-customer revenue" is more trustworthy than a stream of selectively chosen figures, because the reader knows the rule and can see you following it.

How often should you post updates?#

Set the cadence you can hold in your worst month, not your best one. This is the same arithmetic that governs publishing cadence generally, and it applies harder here because a build-in-public archive with a silent stretch in the middle actively damages trust — the silence reads as a bad quarter someone chose not to mention.

What worked for us:

• One monthly retrospective, on a fixed week, on our own blog. Long enough to say something, rare enough to survive a bad month.
• Decision notes as they happen, not on a schedule. Published when a real decision gets made, which is genuinely irregular.
• A named rule for skipped months: if the retrospective doesn't happen, the next one opens by saying so and why. An acknowledged gap costs almost nothing. An unexplained gap costs a lot.

Weekly is achievable for a while and almost nobody sustains it, because a week rarely contains a real decision. Forcing weekly output is how you end up metric-broadcasting.

How do you write a good build-in-public update?#

Four parts, in this order. Every update we're still glad we published has all four; every one that aged badly is missing the third or fourth.

text1. WHAT CHANGED
   The concrete facts. Shipped, removed, broke, decided.
   No framing, no adjectives.

2. WHAT WE DECIDED — AND WHAT WE REJECTED
   The options on the table, and why this one.
   The rejected option is the informative half.

3. WHAT IT COST
   Time, money, complexity, or something we
   deliberately didn't do instead.

4. WHAT WE'RE STILL UNSURE ABOUT
   The open question. This is the part readers
   answer for you.

Part 3 is what separates a report from an announcement. Every decision has a cost, and an update that doesn't name one is describing a fantasy. Part 4 is what turns readers into contributors — a named open question gets answered; "let us know what you think" doesn't.

A pre-publish checklist we run before anything goes out:

• Is there a decision in here, or only a description?
• Would this still be useful to a stranger in a year?
• Is every number on rung 1, or accompanied by the context that makes it rung 2?
• Have I named a cost?
• Is there anything here that isn't only mine to share?
• Am I saying "we were wrong" anywhere — and if not this month, when?

Where should build-in-public content live?#

On something you own, first. Syndicate second.

The value of building in public is cumulative — it's an archive, not a feed. An archive scattered across social platforms is hostage to their policies, their search, and their willingness to keep old posts reachable. A build-in-public history that can't be read in order isn't a history.

Our order of operations: write the full piece on our own blog, then adapt it into platform-native versions for wherever the conversation is. Adapt, not copy. A retrospective that reads well as a blog post reads like a wall of text on a feed; the same decision needs a different shape on each platform, which is a large part of what the numbers taught us about distribution.

The honest conclusion after twelve months#

Building in public is a credibility asset that compounds slowly and an acquisition channel that mostly doesn't work. Budget it that way and it's one of the best uses of a founder's writing time. Budget it as growth and you'll spend a year disappointed by a channel that was quietly doing something valuable the whole time.

The three things we'd tell someone starting today:

1. Publish decisions, not dashboards. The reasoning is the durable asset. The number is the receipt.
2. State your disclosure rule and hold it. What you consistently won't share makes what you do share believable.
3. Write the reversals. They're the hardest to write, the least fun to publish, and the only ones people remember.

And one practical note: the reason most build-in-public efforts die around month four isn't nerve, it's overhead — turning one decision into a blog post, a thread, and a couple of platform-native posts is more work than the decision itself. That adaptation step is exactly the part worth systematising, so the month you're least motivated is still a month you publish.

Because the whole thing only works if the archive has no holes in it.