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.

Weekly vs monthly: two different jobs

Most people burn out because they try to write a monthly-quality post every week. Split them.

Weekly — ten minutes, low stakes. What shipped, the delta on two or three numbers, one thing you learned or got wrong. It's a status line, not an essay. Nobody expects a weekly update to be interesting; they expect it to exist. The consistency is the signal.

Monthly — an hour, higher stakes. The retro: what moved and why, what you were wrong about, what changes next month, the absolute numbers if you share them. This is the post people bookmark and forward. One good monthly beats four mediocre weeklies for reach — but you only have the material for it because you wrote the weeklies.

Whenever it happens — milestones. Don't save these for the monthly. First paying customer, 100 users, €1k MRR: post it the day it lands, with a link to the page where anyone can check it.

A useful rule for empty weeks: if you can't fill the weekly, ship something smaller and post that. A week with nothing to report is itself worth noticing.

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, using three levels:

• Public absolute — the number itself. Right for anything already discoverable: stars, releases, deploy frequency, status.
• Public relative — "+12% this month", the trend without the base. Where most sensitive revenue ends up.
• Private — visible to you, never rendered publicly. Error rates, churn, per-customer anything.

The test that settles most cases: does this number help a competitor more than it helps a reader? Stars, uptime, and commit activity fail that test harmlessly. Churn, acquisition cost, and traffic sources usually don't — they describe the shape of your business rather than proving you're building one.

One rule that saves regret: you can promote a metric from private to public, but you can't quietly take it back. Un-sharing a number people have been watching reads worse than never sharing it. Start conservative, open up later.

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.

Proof over promises

The whole practice rests on one asymmetry: claims are free, verifiable numbers are not. "We're growing fast" costs nothing to write, so it carries nothing. A live MRR figure pulled from your payment provider, a status widget wired to a real check, a commit graph anyone can cross-reference — those cost you the risk of being seen on a bad week, which is precisely why they're believed.

In practice that means preferring numbers you don't type. Anything hand-entered drifts, and the first time a reader catches a stale figure, everything next to it turns back into a claim. Metrics pulled from a third-party API (GitHub, Stripe, Polar, Sentry…) carry a live-verified mark on infrapage for this reason — 30+ widget types across 15+ integrations, so most of a normal stack is a connect-and-forget away.

Where it goes wrong

Four failure modes, roughly in the order people hit them:

The launch-only feed. Silence for two months, then a "we're live!" post. That's marketing with a hashtag on it — nothing accumulates between the announcements.

The vanity page. Only the flattering metric is public. Readers notice what's missing faster than you'd expect: a page with revenue and uptime and error tracking reads as honest; a page with one number reads as a pitch.

Manual updates. Hand-maintained dashboards die in about three weeks. If keeping the numbers current depends on you remembering, they'll be wrong exactly when someone checks.

Performance posting. Optimising updates for engagement instead of accuracy — rounding up, timing the screenshot, cropping the axis. It works twice, and then it's the only thing you're known for.

Notice what isn't on the list: actually oversharing something damaging is rare. Almost everyone who fails at building in public fails by sharing nothing, consistently.

How the cadence compounds

Nothing about the first two months feels like it's working. Ten likes, three replies, no signups. The payoff is real but back-loaded:

• Months 1–2 — you're writing to nobody. The output is the habit, plus a written record of your own decisions, which is worth the ten minutes on its own.
• Months 3–6 — the same twenty people show up every week. Replies start coming from other builders, and your live page begins collecting links from your own updates.
• Month 6 onward — the archive does the work. Someone lands on one post, follows it to your page, and sees a year of shipping with numbers that check out. Nobody who started last week can reproduce that.

All three stages run on the same small weekly act, and none of them depend on a single post performing well. That's the actual mechanism: you're not building an audience post by post, you're building a track record that a stranger can verify in thirty seconds.

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.

If that place is infrapage: building the dashboard is free, publishing it is a one-time €29 claim and the page stays live, and Pro (€9/mo) is only there if you need private widgets, a custom domain, or hourly refresh. Either way, pick a cadence you can hold on a bad week and start this Friday.