DEV Community

Gingiris
Gingiris

Posted on • Originally published at gingiris.tools

Build in Public in 2026: The Playbook That Took AFFiNE to 60K Stars

In February 2023, on AFFiNE's launch day, we did something that felt slightly terrifying at the time: we shared everything — the star count climbing in real time, the bugs we were scrambling to fix, the Hacker News thread going sideways. (My co-founders thought I was crazy to post the messy parts.)

Two years later, AFFiNE had 60,000+ GitHub stars — and a huge share of that growth traced back to one habit: building in public. Not the polished, after-the-fact case-study version. The live, in-the-open version.

This is the playbook — what to share, where, how often, and the mistakes that make it backfire.


Key Stats: Why Building in Public Works

Lever What it compounds
Public metrics (even small) Trust — concrete numbers beat adjectives
Sharing failures, not just wins Credibility — vulnerability converts faster
Consistent cadence Audience — each update grows the base
Work-in-progress demos Feedback — fixes before you ship the wrong thing
Momentum visible in public Social proof — lowers buyer risk
Time horizon Months-long flywheel, not a launch tactic

What "Build in Public" Actually Means

Building in public is sharing the real, ongoing process of building your product — while you're building it, not after. The point isn't vanity metrics; it's distribution and trust. You turn strangers into an audience that roots for you, gives feedback, and becomes your first users.

It's the organic-trust half of a go-to-market strategy — and for open-source, it's most of the strategy.

What to Share (the 5 Buckets)

  1. Metrics — MRR, signups, stars, traffic. Small numbers are fine; concrete beats vague.
  2. Decisions — why you chose X over Y. People learn from your reasoning and trust your judgment.
  3. Failures — the launch that flopped, the feature nobody used. (Our worst Product Hunt attempt taught my audience more than our best one.)
  4. Milestones — first paying customer, 100 stars, a redesign.
  5. Behind-the-scenes — WIP demos, screenshots, a Loom of you debugging.

What not to share: anything that compromises users, unannounced security issues, or internal conflict.

Where to Build in Public

Pick channels by where your users actually are — and start with one you'll sustain, not all five:

  • X/Twitter — indie/startup audiences; threads + short daily updates.
  • GitHub — for developers, a strong README and active issues are building in public. (See how to get more GitHub stars.)
  • Reddit — niche communities (r/SaaS, r/selfhosted, r/indiehackers); 90% value, 10% promotion. (Reddit marketing without getting banned.)
  • Your blog — the durable, SEO-friendly home base for the journey.
  • Zenn / Qiita — if you're reaching Japanese developers.

Cadence Beats Intensity

The flywheel dies when you go quiet. A sustainable rhythm beats a heroic week:

  • Daily-ish: one small update (a metric, a screenshot, a lesson) on X.
  • Weekly: a longer post — what shipped, what you learned.
  • Per-milestone: a thread or blog post + a Product Hunt launch when there's real new value.

The Mistakes That Make It Backfire

  • Only sharing wins — reads as bragging, builds zero trust. Share the mess.
  • Going quiet — a silent month kills the flywheel. Cadence > intensity.
  • Vanity metrics with no story — "1,000 visitors!" means nothing without the decision behind it. It's storytelling with real numbers, not a metrics dump.

FAQ

What does build in public mean? Sharing the real, ongoing build process (metrics, decisions, failures, milestones) openly while you build — for distribution and trust, not vanity.

What should I share? Metrics, decisions, failures, milestones, behind-the-scenes. Not user-compromising info or internal conflict.

Where? Where your users are — X, GitHub, Reddit, your blog (Zenn/Qiita for Japan). Start with one.

Does it drive growth? Yes, consistently done — it compounds audience, social proof, and feedback over months.

Biggest mistakes? Only sharing wins, going quiet, and vanity metrics with no story.


Related Reading

Written by Iris Wei — co-founder of AFFiNE (60,000+ GitHub stars), 30x Product Hunt #1 winner, currently bootstrapping Analook. June 2026.


🛠️ Want the AI-powered skills behind this?

These strategies are packaged as installable AI agent skills — ready to run inside Claude Code, Cursor, or any agent that supports the skills protocol.

npx skills add Gingiris-1031/gingiris-skills
Enter fullscreen mode Exit fullscreen mode

Browse all 45+ growth, SEO/GEO, and open-source skills at gingiris.tools/skills/ — free, MIT-licensed, built from AFFiNE's 0→60K GitHub star journey.

Top comments (0)