Argushow it workspricingtoolscompareguidesprivacyjoin the waitlist
how it workspricingtoolscompareguidesprivacyjoin the waitlist

guides · founders

Build in public on X

Most build-in-public accounts are diaries nobody reads. Same three posts on a loop: shipped a thing, hit a milestone, grateful for the journey. The version that actually builds an audience is different in one specific way - it gives the reader something they can use. Here is how to do that.

The failure mode: milestone posting

"Day 47 of building in public. Shipped a new feature today. Onwards."

Nothing is wrong with that post except that it contains no information. The reader cannot learn from it, disagree with it, save it, or send it to anyone. They cannot even tell whether you are good at this. It is a status update for an audience that does not exist yet, and it is why so many build-in-public accounts flatline: they are broadcasting to people who have no reason to listen.

The mental shift is small and total. You are not documenting your journey. You are publishing what you are learning, and your journey happens to be where the learning comes from. Nobody cares that you shipped. They care what you found out.

Specifics are the whole game

The single highest-leverage change you can make is replacing every vague noun with a concrete one.

  • "Improved onboarding" becomes "cut onboarding from six steps to two - activation went from 31% to 44% in two weeks".
  • "Landing page overhaul" becomes "rewrote the hero three times. The version that won just says what the product does in seven words. The clever one lost by a mile".
  • "Learning a lot about pricing" becomes "raised the price from $9 to $29. Signups dropped about a third, revenue nearly doubled, and support volume halved because the cheap tier attracted people who wanted a different product".

Look at what the specific versions do that the vague ones cannot. They teach something transferable. They are arguable, so people reply. They contain a number, which makes them memorable and quotable. And they prove you have actually done the thing, which is the only credential that matters in this niche.

Real numbers are the strongest material you have, and founders under-use them out of embarrassment. Your MRR is small. Post it anyway. "$340 MRR, up from $180, from two customers who both came from the same Reddit thread" is more interesting than almost anything a large account will post today, because it is real and it is specific.

Show the mess, not just the wins

A feed of only good news reads as marketing and gets skimmed accordingly. The posts that make people follow are the ones where something went wrong and you explain it honestly.

The refactor that took four days instead of four hours. The feature you built for three weeks that two people used. The customer who churned and told you exactly why. The pricing experiment that went backwards. These are the posts that get saved and quoted, because every other founder is currently inside a version of the same problem and nobody else is describing it plainly.

There is a line, though. Post the failure and what you concluded from it - not the failure as content. "Lost my biggest customer today. Turns out they had been trying to do X with the product and we never noticed. We now ask on the third call." That is useful. Public despair with no lesson is a different genre, and it does not compound.

Cadence: the diary trap

"Day 61 of #buildinpublic" creates an obligation and destroys the quality of the posts, because on day 61 you may have nothing worth saying and you post anyway. Streak-keeping is how build-in-public becomes noise.

A cadence that survives contact with actual building looks more like this. One or two posts a day most days, from whatever you genuinely encountered - a decision, a number, an opinion, something broken. Once a week, something with more weight: a proper breakdown of a problem you solved, or what a month of data actually said. And every day, replies, which is where the reach comes from.

Rotate the shape of the posts. A week of only build updates trains people to skip you. Mix in opinions about your space, reactions to what other people are shipping, and questions where you genuinely want an answer. How often to post on X covers the volume side and what to post on X covers the formats.

How it compounds into an audience

Here is the part that is easy to miss. Build-in-public gives you two things at once: content that is genuinely differentiated, because nobody else has your data, and a reason for people to check back, because there is an unfolding story with an outcome they do not know.

That second thing is the compounding mechanism. Someone who read your pricing experiment wants to know how it ended. Someone who read that you were stuck on activation wants to know if you fixed it. Threads of narrative across weeks turn readers into followers in a way that individual good posts never do. So close your loops. If you posted a problem, post the resolution and reference the original. If you posted a number, post it again next month.

But none of that works if nobody sees the posts. This is the hard truth for founders building in public at a small account: your posts are shown mostly to your existing followers, so a great build-in-public feed with 300 followers reaches 300 people. The distribution has to come from somewhere else, and at this size it comes from replies into other people's audiences. Your posts are what convert someone once they arrive. Your replies are what makes them arrive. Read how to get more impressions and the reply playbook, because they are the missing half of every build-in-public guide.

A few things to avoid

  • Fake numbers or vanity framing. This niche is small and full of people who can do arithmetic. One inflated claim costs you the credibility that took months to build.
  • Every post being a soft launch. If each update ends in a link, people stop reading the updates. Sell rarely and directly rather than constantly and sideways.
  • Only talking about your product. The people worth attracting follow you for how you think, not for feature announcements about software they do not use yet.
  • Waiting until you have something impressive. The early, uncertain, unglamorous phase is the most interesting part and the part almost nobody documents honestly.

Common questions

Do I need revenue to build in public?

No, and waiting for revenue is why most people never start. Pre-revenue building is often more interesting because the decisions are still live. Share the problem, what you tried, and what broke. Zero is a number, and it is more honest than most of what gets posted.

How much should I reveal about my product?

More than feels comfortable. Ideas are not the moat, execution is, and nobody outbuilds you off a screenshot. Keep customer data, unshipped security details, and anything under agreement private. Everything else is fair game, and the specifics are what make the posts worth reading.

Why is nobody engaging with my build in public posts?

Either the posts are milestone updates with no substance, which give a reader nothing to react to, or nobody is seeing them because a small account has almost no reach on its own posts. Check impressions first: if they are tiny, the problem is distribution, and the fix is replying into other people's audiences.

Should I post failures as well as wins?

Yes, with the same specificity as the wins. A failure explained properly is more useful and more credible than a streak of good news, and it is what makes people trust the wins when they come. Post the failure and what you concluded, not the failure as performance.

Where Argus fits

Building in public gives you the material. The distribution is the part founders run out of time for. Argus reads your own X analytics to tell you which stage of your funnel is leaking, then finds the live posts in your niche worth replying to and drafts the reply in your voice - so the twenty minutes you have for X goes into reach instead of scrolling. You always press send. Nothing is posted for you, ever.

post the numbers. show the mess.

Argus · grow on X, on purposehow it workspricingtoolsguides