What to Share Build in Public: 50 Specific Things by Stage

TL;DR

• The "what should I post?" question has 50 specific answers organized by stage.
• Pre-launch: positioning, prep, the messy middle. Launch: the launch itself, early feedback. Early traction: first users, lessons, pivots. Scale: durability, retention, operational stories.
• The mistake to avoid: sharing things from a later stage when you are at an earlier one. Posting MRR screenshots pre-launch reads as inauthentic; posting "first user!" at $50K MRR reads as out of touch.

The most common build-in-public question after "what platform?" is "what do I actually post?" The answer is stage-dependent. This cluster organizes 50 specific share-ideas by where you are in your founder journey. It pairs with what not to share build in public on the negative-list side.

Pre-launch stage (10 things)

The pre-launch period is the hardest to fill with content because the product is not yet visible. The 10 things that work:

1. The problem you're solving — specific, sourced in real conversations
2. Why now / why you — your specific advantage or insight
3. Tool stack decisions — "Picked Cursor + Supabase + Stripe. Why."
4. The first prompt sequence that surprised you — for vibecoders specifically
5. A user interview takeaway — "Talked to 5 consultants this week. The unanimous pain: [specific thing]."
6. Pricing exploration — what you're considering and the trade-offs
7. The single sentence you're trying to nail — and 3 versions
8. A scope decision you're agonizing over — invites discussion
9. A teardown of an adjacent product — "Spent 2 hours with [competitor]. Here is what they get right and where they leave gaps."
10. The build environment / .cursorrules you're starting with

Launch stage (10 things)

Launch week is when the content density is naturally highest. The 10 things:

11. The launch tweet itself — the single high-density message
12. The 15-second demo video — screen recording, no voiceover
13. The first piece of user feedback — quoted with permission
14. The first negative comment + your response — handles credibility
15. The cost-transparency post — "$14 in OpenRouter spend so far"
16. The launch-day numbers thread — "24 hours in: [X] impressions, [Y] trial signups, [Z] paying users"
17. The launch-week retrospective — what worked, what surprised you
18. The pricing experiment results — if you A/B tested
19. A specific user's quote about why they bought — with permission
20. The post-launch decision to keep / cut / change something based on user feedback

Early traction stage (15 things)

Most founders are here for the first 3-12 months. The 15 most-shareable things:

21. Specific commits / ships — daily content from Dev Cards
22. The Tuesday weekly demo — 30-60 second screen recording
23. Operator DM patterns you're seeing — anonymized
24. The bug that almost killed something — with the lesson
25. A "first" milestone — first paying user from outside your network, first $1K week, first user in a specific country
26. A feature you killed — and why
27. A feature a user requested and you shipped — with the user credited
28. The Friday Dev Card post — the engineering story of the week
29. The monthly retro — longer post with real numbers
30. A prompt sequence that produced something interesting — for vibecoders
31. A .cursorrules excerpt — published gist
32. A cost / pricing update — "Raised prices from $19 to $29. Here is what happened."
33. A pattern observation across your customers — "Noticed 60% of consulting customers use [specific feature] within day 1"
34. An honest "what I would do differently" — 30/60/90 day reflection
35. A counter-take to common indie hacker advice — sourced in your specific experience

Scale stage (10 things)

Once you're past ~$10K MRR (and before Belogubov's threshold for ghost mode at $30K), the content shifts to systems and retention:

36. A specific user retention story — how a customer evolved their usage over 6 months
37. An operational story — "Migrated off [tool A] to [tool B]. Here is what we learned."
38. A team / hiring observation — even as solo founder, decisions about contracting / part-timers
39. A long-form post about your system — how you run the business, not just what it does
40. A teardown of your own changelog cadence — what's working, what's not
41. A customer interview synthesis — "Talked to 10 customers. Three patterns I hadn't expected."
42. A specific play that scaled poorly — and the fix
43. A specific play that scaled well — and why it generalized
44. The macro decision in your roadmap — e.g., expanding to enterprise tier, adding a free tier, raising prices
45. The year-end retrospective — annual story that compounds trust

Mindset / cross-stage (5 things)

Things you can share at any stage:

46. Your daily / weekly ritual structure — covered in dev journal to twitter
47. A reading / podcast / video that changed your thinking — with the specific insight
48. A failure with the lesson — not performance vulnerability, real engineering / business failure
49. A specific contrarian opinion — defended with your evidence
50. A question you do not have an answer to — invites operator discussion

What this list deliberately excludes

The 2019 build-in-public list often included items the 2026 list omits:

• Daily MRR screenshots — per Belogubov's threshold, stop above ~$10K
• Gratitude performance posts — "so grateful to my supporters!" — discounted by 2026 audiences
• Milestone-as-content theater — every minor win as if it were a launch
• "Day [X] of 365 days of building" without specific substance per day

The list also excludes things you should keep private (per what not to share build in public).

How to use the list

• Identify your current stage. Most founders are in early traction (items 21-35).
• Pick 4-7 items per week. Rotate through them rather than posting the same type repeatedly.
• Layer in the cross-stage items. Items 46-50 work alongside stage-specific items.
• Adapt the framing to your archetype. A vibecoder's "specific commits" post looks different from a B2B SaaS founder's "specific user feedback" post.

Sibling clusters

• What not to share build in public — the negative list
• Build in public revenue sharing — MRR-specific guidance
• Build in public — the head-term pillar
• How to write build in public tweets as a vibecoder — 30 templates
• When to go ghost mode founder — when sharing stops

FAQ

What if I am at multiple stages simultaneously? Most founders are. You can be pre-launch on a new feature while at early traction on the core product. Mix items from the relevant stages. The discipline is matching the item to the actual state of the thing you are posting about.

Can I post things from a later stage to seem further along? No — operators detect this. Posting "we have 1,000 users!" when you have 4 reads as inauthentic. The honest version of where you actually are produces more engagement than the inflated version.

How often should I rotate through the categories? Roughly: 50% ship / workflow content (items 21-31), 20% reflection / observation (33-42), 15% honesty / failure (24, 26, 35, 48), 10% retrospectives (29, 45), 5% questions / contrarian (49, 50). Exact ratios vary by archetype.

Are these specific to indie hackers? Yes, mostly. For larger / VC-backed companies, the share-list shifts toward roadmap, hiring, product launches, partnership announcements. The indie-hacker-specific share-list emphasizes daily ships, cost transparency, and individual-founder voice.

What if I run out of things to share? Usually the issue is not running out of material — it is not noticing the material as shareable. Run a Vibe Journal ritual for a week; you will discover 10-15 shareable things you had not surfaced.

Building is no longer the bottleneck. Visibility is. buildinpublic.so is narrative infrastructure that runs inside your building workflow — Dev Cards supplies the ship / workflow items automatically, Loudy drafts the reflection items in your voice, and Vibe Journal captures the daily inputs that fuel the larger retro items.