What to post when you build in public: turning your project into 30 posts

The hardest part of building in public isn't writing a post — it's the blank page. You sit down, think “what do I even post about,” and close the tab. This is a fix for that: a repeatable way to turn one project into thirty specific posts, without ever writing “excited to share my journey” again.

Why “share your journey” is terrible advice

Generic prompts produce generic posts, and generic posts get ignored. “Talk about your why,” “introduce yourself,” “post a milestone” — these could apply to any founder, which is exactly why they land flat. The posts that actually get read are the ones only you could write, because they're rooted in the specific details of your specific build.

So the real skill isn't “being creative.” It's learning to mine the specific things already sitting in your work.

The nine sources of build-in-public content

Every project contains these. Walk through them and you'll have more ideas than you can post:

1. Decisions

Every “X over Y” is a post. Why you chose your database, your pricing model, your first channel. Decisions carry tension and teach something.

2. Bugs and near-disasters

The weirder the failure, the better. “The bug only appeared on the third of the month” is a hook people can't scroll past.

3. Users

Your first signup, a surprising piece of feedback, a feature request that changed your roadmap, your first churned customer and why.

4. Numbers

MRR, signups, conversion rate, time saved. Even small numbers travel if they're real and specific. “3 paying users” is more honest and more shareable than “growing steadily.”

5. Things you almost cut

The feature you nearly killed, the scope you cut to ship. What you leave out is as interesting as what you keep.

6. Lessons

Something you now believe that you didn't last month. The more it cost you to learn, the better it reads.

7. Contrarian takes

The received wisdom in your niche that you think is wrong — backed by your own experience, not just attitude.

8. Behind-the-scenes

The unglamorous reality: the spreadsheet, the support email at 11pm, the refactor nobody will ever see.

9. What you're stuck on

Asking for help is content. “How do you all handle X?” posts get replies, and replies are reach.

Turn one project into thirty posts

Take those nine sources and instantiate each with two or three real details from your build. A changelog tool becomes: “why we auto-draft from merged PRs,” “the subscriber-digest feature that almost didn't ship,” “what indie founders get wrong about changelogs,” and so on. Nine sources × three or four angles each = a month of posts from a single week of work.

The key is that each idea references something real — the actual tech, the actual user, the actual number. If an idea could apply to any founder, throw it out.

Keep a swipe file

The moment something specific happens — a bug, a user reply, a decision — write one line about it somewhere you'll see later. Most great build-in-public posts are lost because the founder didn't capture the detail while it was fresh. A running note beats trying to remember what happened this week.

Batch the writing, not the thinking

Ideas should be captured continuously, but writing is better batched. Once a week, take your captured moments and turn them into posts in one sitting. This separates “what should I say” (the hard part) from “write it down” (the easy part), so you're never staring at a blank page.

This is the exact problem the right tools solve: hand you specific ideas from your project, then help you write them fast. But the method works with a notes app too — the tool just removes the friction.

The bottom line

You are not out of things to post. You have a project full of specific decisions, bugs, users, and numbers — that's thirty posts minimum. The work isn't inventing content; it's noticing what already happened and saying it plainly. Start by writing one line about the most interesting thing that happened today. Then post it.