Building in Public: What We Got Right and Wrong

Building in public has become a default strategy for startups. Share the journey, attract an audience, convert them to users. Simple, right?

Not exactly.

We've been building Bloomberry in the open since the first commit. Here's what actually happened.

What We Got Right

Shipping updates as content. Every product update became a LinkedIn post. Not a "we shipped feature X" announcement — those get ignored. Instead, we framed each update as a problem-solution story. "Users kept telling us X. We tried A, B, and C. Here's what worked." This turned product development into content development. Two birds, one stone.

Showing the messy middle. The posts about what went wrong got 4x the engagement of posts about what went right. People don't want curated success stories. They want to see the decision-making process — especially the parts where you're uncertain.

Engaging replies as research. The comments on build-in-public posts are a free focus group. When we posted about considering a feature, the replies told us exactly what mattered to users before we wrote a single line of code.

What We Got Wrong

Over-sharing the roadmap. We told people about features months before they shipped. When priorities changed (as they always do), we had to explain why something "promised" wasn't happening. We didn't promise anything — but that's not how it felt to the audience.

Confusing building in public with marketing. Not every development update makes good content. Database migrations, dependency upgrades, bug fixes in edge cases — nobody cares about these. We learned to filter for updates that contain a transferable insight, not just a status report.

Neglecting the product for the content. There were weeks where we spent more time crafting the build-in-public post about a feature than actually building the feature. The tail was wagging the dog.

The Framework We Use Now

After 18 months, here's the operating model:

1. Ship first, write second. The content comes from the reflection on what happened, not from narrating it in real-time.
2. One update per week maximum. Scarcity increases the signal-to-noise ratio.
3. Every post must contain a lesson someone outside our specific domain could use. If the takeaway only applies to AI writing tools, it's too narrow. If it applies to any builder, it's a post.
4. Separate the build-in-public channel from the product channel. Our LinkedIn is for operational insights. Our changelog is for feature updates. Mixing them diluted both.

Would We Do It Again?

Absolutely. Building in public accelerated our growth by at least 6 months. But we'd do it more selectively. The "in public" part should serve the "building" part, not the other way around.