Building in public is advice that sounds obviously correct and is executed badly almost universally.
The failure mode is consistent: someone posts "Day 12 of building my SaaS 🚀" every morning, gets three likes from other people posting the same thing, concludes it does not work, and stops.
They are not wrong that it did not work. They are wrong about why.
Why Most Build-in-Public Posts Get Ignored
Milestones are not content. "Day 40" means something to you and nothing to anyone else. Nobody is following your day count. There is no story in a number that increments.
Nobody is invested in your journey yet. Founders who post updates successfully usually built an audience first, then documented for it. Starting from zero, you have to lead with something useful rather than something personal.
Vagueness kills it. "Made great progress on the backend today!" is unreadable. There is nothing to learn, react to, or disagree with.
The fix in every case is the same: post the specifics, not the status.
What Actually Gets Read
Problems you got stuck on
The single most reliable format. "Spent three days on a bug that turned out to be a timezone issue in my cron job — here is what I misunderstood about UTC handling in Postgres."
This works because it is useful to someone searching that exact problem, it demonstrates competence more convincingly than any claim, and it invites people who know more to reply.
Decisions with reasoning
"Chose Firebase over Supabase, here is the specific reason" is interesting. "Using Firebase!" is not.
Show the trade-off you weighed. People engage with reasoning far more than conclusions, and the comments often teach you something.
Numbers, especially unflattering ones
Real numbers outperform everything. Revenue, signups, churn, costs, conversion rates.
Bad numbers outperform good numbers. "Launched, got 12 signups, expected 200, here is what I think went wrong" gets read far more than a success post — because almost everyone else is quietly having the same experience and nobody is admitting it.
Things you were wrong about
"I spent two months building a feature nobody used" is genuinely valuable and rare, because it costs something to admit.
The work itself
Screenshots of the actual interface. A short screen recording of the thing working. Concrete beats descriptive every time.
Where to Post
X/Twitter is where #buildinpublic concentrates. Fast feedback, short shelf life, and heavily dependent on consistency.
Reddit — r/SideProject and r/indiehackers — gives blunter and more useful feedback. Post the thing itself with a specific question, not a status update. Participate for a few weeks before posting your own.
Indie Hackers rewards depth. Longer posts about revenue, mistakes, and specific decisions do well; announcements do not.
Hacker News is not a build-in-public venue, but a Show HN with a genuinely interesting technical decision behind it can outperform everything else combined.
Your own site is the one people skip, and the only one you own. Posts on someone else's platform disappear into a feed within hours. A post on your own domain accumulates search traffic for years — and a build log gives visitors a reason to return, which a static product page does not.
The reasonable approach: write it where you own it, then share it where people are.
A Cadence That Survives Contact With Reality
Daily posting is why most people quit. It is a lot of output when you also have a product to build, and it forces you to post on days when nothing interesting happened — which trains people to ignore you.
Better: post when something is genuinely worth posting, aiming for roughly twice a week. A useful weekly post beats seven filler ones.
Track a small list of things worth writing up as they happen — a bug that taught you something, a decision you agonised over, a number that surprised you. Post from that list rather than from obligation.
What Building in Public Actually Gets You
Worth being precise, because expectations here are usually miscalibrated.
It will not get you customers directly. Your audience is mostly other makers, and other makers are usually not your buyers.
It will get you early feedback from people who understand the problem, before you have wasted months.
It will get you a small group who recognise your name — which is what makes your second launch outperform your first.
It compounds across products. The real return often arrives on the next thing you build, when you start with 200 people who already know you ship.
It keeps you honest. Publishing your numbers makes it harder to quietly avoid looking at them.
The Uncomfortable Parts
You will post to near-silence for a long time. Months. This is normal and not a signal to stop.
Publishing revenue attracts unpleasant attention. Copycats, spam, and occasional hostility. Many experienced makers share percentages and directional changes rather than exact figures, which is a reasonable middle ground.
It can become procrastination. Writing about building feels like building and is not. If posting is displacing shipping, post less.
Public commitments can trap you. Announcing a feature makes it harder to abandon when you learn it is wrong. Commit to problems publicly, not to solutions.
How to Start This Week
Pick one platform. Just one.
Write about the last thing that took you longer than expected. Be specific about what confused you.
Post it. Expect little response.
Do that twice a week for two months before evaluating.
Keep the posts on your own site as well, so they accumulate somewhere you control.
The bar is low: be specific, be honest, and post the parts most people leave out. That is genuinely most of it.
If you want somewhere to keep your build log alongside your product, BuiltByIndies has one built in — free, and attached to a community of people doing the same thing.
