Build in public: a GitHub-release-driven growth loop

The hardest part of building in public is not writing. It is deciding what to write and remembering to do it at all. When you anchor your build-in-public habit to your GitHub releases, both problems disappear. The release tells you when to post - you just shipped something - and it tells you what to post, because the release notes already describe the change. You are never inventing a reason to show up; the reason shipped itself.

This matters more for indie hackers than for anyone else, because you are the engineer, the marketer, the support team, and the founder simultaneously. You do not have spare hours to run a content calendar. But you do ship. A release-driven loop means your marketing cadence is automatically tied to your building cadence: ship more, post more; ship less, post less. The marketing never gets ahead of the reality, which is exactly the authenticity build-in-public audiences reward.

There is also a credibility dividend. Anyone can tweet a roadmap. Far fewer people consistently show the work landing. A stream of posts each tied to a real, dated, versioned release is hard to fake, and audiences feel the difference. The release is your proof, and proof is the entire currency of building in public.

A lot of build-in-public content is just numbers: revenue charts, user counts, follower milestones. They spike engagement and teach the audience nothing. The accounts that build a durable following tell a continuous story - what problem you are chasing, what you tried, what broke, what you learned, and what you shipped because of it. A release is a perfect chapter break in that story.

Frame each release as a beat in an ongoing narrative rather than an isolated announcement. Instead of shipped v0.4.2 with retry handling, write the version readers can follow: posts kept silently failing when a provider had a blip, it was eroding trust, so this release retries automatically and tells you when it does. Same release, but now it has a problem, a stake, and a resolution. That is a story, and stories are what people subscribe to.

Let the narrative include uncertainty and reversals. The decision you almost made and backed out of, the feature users asked for that you decided not to build, the bug that taught you something about your own product - these are the posts that make people feel they are watching a real thing get built. Polished certainty reads like marketing. Honest process reads like a builder worth following.

One release should become several posts, but not the same post pasted everywhere - the build-in-public crowd notices cross-posting instantly. The loop is: write the core narrative once, then adapt it to the grammar of each channel where your audience lives. The facts stay constant; the framing flexes.

For most indie hackers, the effective mix is X for reach and conversation, a build-in-public community on Discord or a forum for depth and feedback, and a periodic longer-form recap somewhere owned, like a changelog or a short blog. X gets the compressed beat with a hook. The community gets the honest detail and an explicit ask for feedback. The owned recap collects the releases into a story search engines and new visitors can find later. Each surface plays a different role in the loop.

The key discipline is to make the adaptation fast. If reformatting for three channels takes thirty minutes per release, the loop dies. Either keep templates that you fill in, or let a tool draft the channel-native versions from the release notes so you spend your time choosing the angle and adding the human texture, not retyping the same idea three ways.

Time budget is the whole game for a solo builder. The realistic target is fifteen minutes from release to posted, including the human touches. Beyond that, the loop competes with building, and building always wins, which means the marketing silently stops. Designing for the low time budget is not laziness; it is the only way to get the consistency that makes building in public work.

Three habits keep the cost low. First, write release notes as if a human will read them, because the better your notes, the less rewriting your posts need - your changelog becomes your first draft. Second, keep a small set of reusable post shapes so you are filling in a known structure, not designing each time. Third, automate the mechanical part: detecting the release and producing channel-native drafts, so your fifteen minutes goes to angle and voice rather than formatting and copy-paste.

This is precisely where a release-driven tool earns its place. S2P watches your GitHub releases, drafts the channel-specific posts from the release notes in your voice, and routes them for your approval before anything goes live. You stay the author and the editor; the tool removes the blank page and the retyping. The point is not to take you out of the loop - it is to make the loop cheap enough that you actually keep doing it after the novelty wears off.

The underrated payoff of building in public is not reach; it is the feedback. When you announce a release with an honest description of what it does and does not do yet, you invite exactly the people who care about that problem to tell you what they need next. For an indie hacker without a research budget, that is the cheapest, highest-signal product input available.

Make the ask explicit and specific. Vague requests like let me know what you think get silence. Concrete ones like this only handles X so far - would Y be more useful to you? get real answers, because you have given people an easy, specific thing to react to. The release gives you a natural, non-needy reason to ask, since you are reporting progress, not begging for validation.

Then close the loop publicly. When a future release ships something a follower suggested, say so and credit them. This does two things: it shows the audience that engaging with you has real consequences, which dramatically increases future engagement, and it converts followers into something closer to collaborators. A growth loop that also improves the product is the rare kind of marketing that pays for itself twice.

New builders fixate on the big launch - the Product Hunt day, the viral thread, the Show HN that hits the front page. Those moments are real, but they are spikes, and spikes decay. The audiences that turn into customers and advocates are built by the boring, repeated act of showing up with each release, month after month, long after the launch dopamine is gone.

The compounding is quiet and then sudden. For the first couple of months, a release-driven loop feels like shouting into an empty room. Then the back catalog starts working for you: a new follower scrolls your history and sees a year of consistent shipping, which is the single most persuasive thing a builder can show. Consistency is not just a tactic; it is the proof that you are the kind of team that finishes things, which is what people are really deciding when they choose to follow or buy.

So optimize for survivability over intensity. A modest post on every release for a year beats a brilliant launch week followed by silence. Set the bar low enough that you clear it even when you are busy, automate the parts that threaten that bar, and let the releases - which you are going to ship anyway - carry the cadence for you.