Most indie hackers know they should be building in public. Almost none of them still are by week three. Not because the idea is wrong — because the habit is expensive in exactly the currency they don't have: attention that isn't going into the product. This is a practical guide to doing it anyway, without it costing you ship time, and without the account going quiet the first week things get busy.
Why build in public actually works for indie hackers
Traditional marketing asks you to make a promise and hope someone believes it. Build in public flips that: you show the work, and the audience draws its own conclusion. For a solo developer with no brand, no budget, and no case studies, that's the only kind of proof available — and it happens to be the kind people trust more than an ad.
The second reason it works is that it compounds. A single tweet about a feature you shipped today gets maybe a few dozen views. But a year of daily shipping posts is a searchable, screenshot-able history of a real project getting built by a real person. Someone who finds post #4 will scroll and find #3, #2, #1 — and see the shape of a founder who ships. That's distribution you can't buy, because it only exists if you actually did the work, consistently, in front of people.
This matters more for indie hackers than for funded startups. A funded startup can afford a launch splash, paid ads, a PR firm. An indie hacker's only renewable resource is the fact that they're building every day — which is precisely the thing build in public turns into an asset instead of a private habit nobody sees.
What to share (and what to leave out)
The build-in-public feeds that hold attention are specific, not vague. "Working on the app today" gets scrolled past. "Added Stripe webhooks, killed a race condition that was double-charging refunds, +180/-40 lines" gets read, because it's a real fact about real work. A useful build-in-public post usually contains one of these four things:
- Shipped changes. What actually went out today — a feature, a fix, a removal. Concrete beats abstract every time.
- Numbers. Commit counts, lines changed, streak length, signups, response times. Numbers are the fastest way to prove momentum without asking anyone to take your word for it.
- Decisions. Why you chose Postgres over a queue, why you cut a feature from v1, why the pricing changed. Decisions show judgment, and judgment is what people are actually betting on when they follow a solo founder.
- Misses.A bug that shipped, a week where nothing got built, a plan that didn't pan out. Misses are what make the wins believable. An account that only ever wins reads like a highlight reel, and highlight reels get ignored.
What to leave out is almost as important. Skip vague motivational posts with no specifics attached — "grinding today, big things coming" is filler, and filler trains your audience to skip you. Skip internal jargon that means nothing outside your own head; if a post needs three lines of context before it makes sense, it's not ready to post. And skip code contents — what matters to an outside audience is what changed and why, not the diff itself.
A cadence that survives a real week
The single biggest failure mode in build in public isn't bad content — it's inconsistency. An account that posts brilliantly for ten days and then vanishes for a month reads worse than one that posts something small every single day it ships. Consistency is the actual product; the content is just the packaging.
The cadence that survives contact with a real week has two layers:
- Daily, lightweight.One short post on any day you committed code — a stat line, not an essay. "Day 14 of building [project] · 9 commits · +240 −60 · streak alive" takes ten seconds to read and, if it's automated from your actual git history, zero seconds to write.
- Weekly, cumulative.A recap post every Monday that rolls up the week — total commits, the biggest thing shipped, best day. This is the post that catches people who don't see every daily update, and it's the one worth spending two extra minutes on.
Notice what's missing from that list: nothing that requires you to sit down, think of something to say, and write it from scratch every day. That step is exactly where most people quit — not because they ran out of things to share, but because "remember to write the update" is one more task competing with actual product work, and product work wins every time you're tired.
Where to post it
Start on X. It's where the build-in-public community already lives, where other indie hackers and early customers are already looking for exactly this kind of update, and where a short stat-and-screenshot post performs best as a format. If you're starting from zero, this is the one place worth showing up daily.
From there, syndicate — don't rewrite. The same shipping update, posted to LinkedIn if your buyers are more B2B, or to Bluesky if your audience skews there, costs almost nothing once the core post exists. The mistake is treating each platform as a separate writing task; treat it as one update, three destinations.
Finally, keep a permanent record somewhere search engines can find it. A tweet is gone from most people's feed in an hour; a changelog blog on your own domain is still indexable a year later, and it's often how people find a project months after you shipped the thing they were searching for. Our own build page at gittomarket.io/w/gittomarket is a working example of this: every shipping day becomes its own SEO-indexed article automatically, on top of the daily card that goes out to social.
The consistency problem, honestly
Most build-in-public accounts stop by week three. It's rarely a content problem — it's a workflow problem. The typical failure looks like this: day one and two are easy, because starting something is motivating. By day five, remembering to check your git log, summarize the day, write a caption, and post it competes directly with actually shipping. By week three, the choice between "write today's update" and "fix the bug that's blocking a customer" isn't close, and the update loses. A few skipped days turn into a dead account, which is worse than never having started one — an abandoned build-in-public feed is itself a signal, and not the one you want to send.
The fix isn't more discipline. It's removing the parts of the habit that depend on discipline in the first place.
Automating the boring 80% from your git history
Here's the honest pitch, in one section, not the whole article: most of a build-in-public post is mechanical. The commit count, the lines added and removed, the files touched, the streak length — all of that already exists in your git history the moment you push. The only genuinely human part is deciding what a given week meant, which is exactly the part worth spending your own two minutes on.
That's the gap gittomarket is built to close. It reads your GitHub commits — counts and messages only, never code contents — and turns each shipping day into a designed stat card that posts automatically to X, LinkedIn and Bluesky each morning. Captions are written for your actual target customer rather than for other engineers, and you can review them from Telegram before they go out or let them post themselves. Days with zero commits are skipped automatically, so the feed never fills with filler. Alongside the daily cards, it maintains a public build page — gittomarket.io/w/your-slug, or your own domain via a CNAME — with a waitlist and an SEO-indexed article auto-written from each shipping day, plus a g2xCLI and MCP server if you'd rather trigger it from your terminal or editor than a dashboard.
None of that replaces judgment — it just removes the ten minutes of mechanical work that's the actual reason most people quit. If you want to see how much of a gap there is between what you've shipped and what you've told anyone about it, the ship gap tool will show you, free, against your own repo.
The free tier covers 10 auto-posts a month plus a 14-day trial of the full Pro plan, no card required. Pro is $29/month once you're past the trial; the first 20 people who join the founding beta lock in $9/month forever. If you're running a team instead of a solo project, the same system works there too — see the indie hackers and solo founders pages for how the setup differs by stage.
Where to go from here
Pick one platform, one cadence, and start today — with whatever you shipped this week, not a perfect origin story. If you want more on the marketing side of this without the busywork, we cover the broader system in Marketing for Developers Who Hate Marketing. If you specifically want your commits turning into posts without touching a scheduler, see How to Auto-Post GitHub Commits to X/Twitter for a comparison of the ways to do it, including doing it by hand.