Building in public means sharing the actual work of building your company as it happens: the real decisions, the reasoning behind them, the numbers when you can, and the mistakes you made along the way. For a devtools company it is one of the most natural content strategies there is, because your audience is builders, and builders are genuinely curious about how other people build. Done well, it produces content only you could make, which is exactly the kind that stands out in a feed full of generic advice. Done badly, it turns into a performance, which your audience spots immediately and trusts less for.
The appeal is that it sidesteps the hardest part of content, which is having something to say that nobody else can. You are always doing the work. Building in public is just letting people watch the parts worth watching.
Why builders trust it
Developers respect other people who build things, and they respect specifics. A post that walks through a real architectural decision, the tradeoff you weighed, why you chose the path you did, and what it cost, is interesting to exactly the people you want reading, in a way no polished announcement ever is. The honesty is the point. Showing the actual work, including the parts that did not go smoothly, reads as credible in a way that a highlight reel does not.
It also builds a particular kind of audience: people who feel invested in your progress because they have been following the story. That audience shows up when you launch, applies when you hire, and pays attention when you raise, because they have watched you earn it. This compounds the same way a founder’s LinkedIn presence does, and the two work well together.
What to actually share
The content worth sharing is the real, specific story behind the work. The decision you agonized over and how you resolved it. The metric that surprised you. The thing you tried that failed and what you learned. The reasoning behind a pricing change or a product direction. Specificity is what makes it land, so reach for the real numbers and the real detail rather than vague reflections, because vague is where building in public turns into generic founder-content noise.
Your product changes are a natural source for this. A meaningful release, the reasoning behind a feature, the problem it solves, is both a building-in-public moment and a marketing one, which is part of why I treat the changelog as a marketing surface. The work you are already doing is the content; you just decide which parts are worth telling and tell them honestly.
What to keep private
Building in public is selective honesty, not radical transparency, and the difference matters. Some things genuinely should not be shared: security details that could be exploited, information that hurts a customer or an employee, revenue or fundraising numbers your investors and team have not agreed to make public. Oversharing in the name of authenticity can do real damage, and a thoughtful audience does not actually expect you to disclose everything.
So decide the line deliberately. Share the real story within the bounds of what is safe and fair to disclose, and be comfortable keeping the rest private. The honesty that matters is being truthful about what you do share, not sharing everything. A founder who is clearly genuine about the parts they discuss earns trust even while keeping plenty off the table.
Keep it real, not performed
The failure mode is turning building in public into a performance: manufactured vulnerability, humble-brags dressed as lessons, a curated struggle that exists to look relatable. Your audience, who are builders themselves, can tell the difference between someone sharing real work and someone performing the aesthetic of it, and the performed version costs you the credibility the real version earns.
The fix is to only share what is actually true and actually interesting, and to skip the posts where you have nothing real to say. Not every week has a great building-in-public story in it, and forcing one is worse than staying quiet. Share when there is something genuine worth sharing, keep it specific, and let the real work speak. If you want help turning what you are already building into content that resonates, that is the work I do, and you can tell me what you are working on right now.
