What should I post when building in public?
What should I post when building in public?
TL;DR
- What to post when building in public is specifics: real numbers, real decisions, and honest failures that only you could share.
- Generic progress updates like "made great progress today" get ignored because they carry no information.
- The most engaging posts name an exact problem, an exact number, or an exact lesson.
- Building in public works because it compounds attention before you ever need to sell anything.
---
Why most build in public posts get ignored
The phrase build in public has been repeated so often that most people now post the same hollow updates. "Big day today." "Excited to keep shipping." "Grateful for this community."
These get ignored because they contain no information. There is nothing for a reader to learn, react to, or remember.
Building in public works when it gives people something real. A specific number, a hard decision, a mistake you made. That is what people stop scrolling for.
The test for any post is simple. Could anyone have written this about any product. If yes, do not post it.
The three things that actually get engagement
Across the founders who build in public well, three kinds of posts consistently outperform.
Real numbers
Specific metrics, good or bad, draw attention because they are concrete and rare. Most founders hide their numbers, so sharing yours stands out.
"Went from 12 to 47 signups this week after changing one line on the landing page" is a post people engage with. They want to know the line. They remember you.
Vague growth talk does the opposite. "Things are growing nicely" tells no one anything.
Specific decisions
Walk through a real choice you made and why. Pricing, a feature you cut, a tool you switched away from.
Decisions are interesting because the reader is often facing the same one. You are doing their research for them, in public, with your real context attached.
The detail is what makes it useful. Name the options, name the tradeoff, name what you picked.
Honest failures
The most underused category, and often the most effective. A real failure, told plainly, earns more trust than any win.
"I spent three weeks building a feature nobody used and here is how I figured that out" is a post people share. It is honest, specific, and rare.
Honesty is also a filter. The people who respond to it are the ones who will actually root for you.
Commit summaries versus the voice memo approach
There are two common ways to generate build in public content, and they produce very different results.
The first is the commit summary. You list what you shipped this week, pulled from your git history. "Added auth, fixed the dashboard, improved loading speed."
This is easy to write and almost nobody cares. It reads like a changelog, because it is one. There is no story, no reason, no human in it.
The second is the voice memo approach. You talk through what you worked on, why it mattered, what was hard, and what you decided. Then you turn that into a post.
The voice memo version captures the thing the commit log strips out: your reasoning and your personality. That is what people actually follow. The difference between the two is the difference between a log and a story.
What to never post
Some things hurt more than they help. Avoid these.
- Pure hype with no substance. "This is going to be huge" with nothing behind it reads as empty.
- Manufactured vulnerability. Fake struggles for engagement get spotted and resented.
- Other people's numbers as your own. Borrowed metrics destroy the trust the format is built on.
- Endless milestone counting. "Day 47 of building in public" with no content is just noise.
- Complaints with no insight. Venting is fine in private, but a public complaint needs a lesson attached.
The pattern is the same. If a post is performance instead of information, skip it.
A simple weekly framework
You do not need to post daily. One or two strong posts a week beats seven empty ones.
Each week, ask yourself three questions. What number changed and why. What decision did I make and what was the tradeoff. What did I get wrong and learn from.
Answer whichever one has a real story behind it that week. If none do, it is fine to post nothing.
The goal is not volume. It is to build a record of being a specific, honest person making real decisions. That record is what people come to trust, and trust is what eventually sells.
Build in public is not a content treadmill. It is the slow accumulation of credibility through telling the truth about your work.
---
Frequently Asked Questions
How often should I post when building in public? One or two substantive posts a week is more effective than daily empty updates. The format rewards quality and honesty over frequency, so it is better to wait for a real number, decision, or lesson than to post a filler update.
What kind of build in public posts get the most engagement? Posts with real numbers, specific decisions, and honest failures consistently outperform generic progress updates. These work because they give the reader concrete information they can learn from, which vague "making progress" posts never do.
Should I share my revenue and metrics publicly? Sharing specific numbers, even small or declining ones, tends to draw far more engagement than hiding them, because real metrics are rare and concrete. You should only share what you are comfortable being permanent and public, but transparency is usually the higher trust choice.
Is building in public worth it if I have a small following? Yes, because building in public compounds, and the early posts are how you grow that following in the first place. A small audience that trusts you because you have been specific and honest is far more valuable than a large one that scrolls past generic updates.
---
Vibs.io turns a quick voice memo or your weekly GitHub diff into a build in public draft that sounds like you: try it at [vibs.io](https://vibs.io).