Building in public: the practical guide for solo devs and indie hackers

Building in public means developing your product with the process visible: sharing your metrics, decisions, failures, and progress openly instead of working behind a curtain until launch. Solo developers and indie hackers use it to build an audience while they build the product — so that on launch day, someone is actually watching.

That's the whole idea. The rest of this guide is about doing it without wasting time or leaking things you'll regret.

Why it works

Building in public compounds three things that solo founders are chronically short on:

Distribution. Every progress update is a small, honest piece of marketing. You don't need a content strategy — the work is the content. People follow journeys, not products.

Accountability. A public commitment to ship is harder to abandon quietly. Streaks, milestones, and visible numbers keep you moving on the weeks motivation doesn't.

Trust. Anyone can claim traction. Showing real, verifiable numbers — actual MRR, actual uptime, actual commits — separates you from the launch-day screenshot crowd. This is why live data beats a bragging thread: numbers that update themselves can't be cherry-picked.

How to start

You don't need an audience to begin. The practical sequence, in order (there's a more detailed step-by-step guide to building in public if you want it):

1. Pick one place to share — X is the default home of the community, but the same approach works anywhere.
2. Decide which metrics you're willing to show. Public revenue is common but optional.
3. Put your numbers somewhere permanent — a public page people can check anytime, not just when you post.
4. Share the process weekly: what you shipped, what broke, what you learned.
5. Show up when others share. Build-in-public is a community, not a broadcast channel.

If the term is still fuzzy, there's a short definition of building in public — and if you want to see what it looks like in practice, browse some real build-in-public examples with live numbers.

What to share (and what actually resonates)

The updates that work are specific and honest:

• Milestones — crossing 100 users, first €1k MRR, 1,000 GitHub stars. Round numbers travel.
• Weekly numbers — MRR, signups, traffic, with the delta from last week. Growth rates are more interesting than absolutes.
• Decisions — why you killed a feature, changed pricing, rewrote something. The reasoning is the value.
• Failures — the launch that flopped, the churn spike. These outperform wins because they're rarer and more useful.

What doesn't work: vague "grinding 💪" posts, screenshots with the numbers cropped out, and anything that reads like a press release.

The oversharing problem

The most common reason developers don't build in public: some numbers are sensitive. Your revenue might be fine to share; your customer list, churn details, or exact user count might not be.

The fix is granularity, not abstinence. Decide per metric what's public. Share the growth rate but not the absolute. Show uptime and stars publicly, keep error rates and revenue private. This is exactly the problem infrapage is built around: every widget on your page is individually public or private, and sensitive metrics can be shown as growth-only — "+12% this month" without the underlying number.

Keep the proof somewhere permanent

Posts disappear from timelines in a day. The compounding value of building in public comes from having a stable place where your numbers live — a page you can link from your README, your bio, and every update you write. Whatever tool you use (here's an honest rundown of build-in-public tools), the habit matters more than the stack: make the numbers public, keep them current, and let the work speak.