How to build in public on X: a practical guide for indie hackers

Most build-in-public advice stops at “just share your journey.” That's useless. Nobody wakes up wanting to read your journey — they want a specific lesson, a number that surprises them, or a mistake they can avoid. This is a practical guide to building in public on X: what to actually post, how often, and how to turn shipping code into an audience that shows up when you launch.

What building in public actually means

Building in public means sharing the real, in-progress work of making your product — the decisions, the numbers, the dead ends — while you're still in the middle of it. Not a polished case study after the fact. The value is in the mess: people trust a founder who shows the bug that took three hours more than one who only posts wins.

X is the default home for this because it's real-time, the indie-hacker community is already there, and a single honest thread about going from $0 to $1k MRR can reach tens of thousands of exactly the right people. The catch: the bar for “interesting” is high, and generic updates disappear.

The only rule that matters: be specific

Every good build-in-public post trades generality for specificity. Watch the difference:

• Generic (ignored): “Made great progress on the app today! Excited for what's next 🚀”
• Specific (read): “Spent 3 hours on a render race that only showed up with 2+ tabs open. The fix was one line. It's always one line.”

The second one works because it's a real scene with a number and a small universal truth. You don't need to be a great writer — you need to notice the specific detail that actually mattered and lead with it.

What to post: the seven angles

The blank page is the real enemy, not writing. When you're stuck, pull from these angles — each one is sitting in your actual work right now:

1. The stack choice. Why you picked X over Y, and what it cost you. (“Chose Supabase over Firebase because RLS meant I didn't have to write an auth layer. Regret level: zero.”)
2. The bug that nearly broke you. The weirder the failure, the better the post.
3. The first user. The moment someone you don't know signed up, and what they did next.
4. The feature you almost cut. Tension is content. What did you nearly kill, and why did you keep it?
5. A traction milestone. First dollar, first 10 users, first churned customer. Numbers travel.
6. A hard-won lesson. Something you now believe that you didn't two weeks ago.
7. A contrarian take on your space. The thing everyone in your niche says that you think is wrong.

If you want a running list of these tailored to your project, that's exactly what we built the idea board for — but you can do it by hand with the seven above.

How often to post

Consistency beats volume, but volume beats perfectionism. A realistic cadence that compounds:

• 1 substantive post a day — a build update, a lesson, or an observation. This is your core.
• 1 thread a week — a deeper story or breakdown that can travel further than a single post. (Here's how to structure one.)
• Replies daily — the actual growth channel. Thoughtful replies to bigger accounts in your niche get you seen faster than any post.

Miss a day, don't agonize. The founders who win at this treat it like a gym habit, not a performance.

Write the hook first

On X, the first line is the post. If it doesn't earn the second line, nothing else you wrote matters. Cut the throat-clearing (“So I've been thinking…”) and open cold on the most interesting fact:

Before: “Wanted to share a quick update on the product today.”
After: “Deleted 3 onboarding screens. Signups went up.”

Same information, completely different fate. When in doubt, delete your first sentence — the real hook is usually the second one.

Turn shipping into distribution

The whole point of building in public is that distribution stops being a separate job. Every commit, every bug, every user email is raw material. The trap indie founders fall into is spending the building energy on the product and having nothing left for the posts — so the work stays invisible.

The fix is a system: capture the specific thing that happened, write it in your own voice, and ship it before you talk yourself out of it. That's the whole loop. If you want it to sound like you and not like a template, that's the one thing you can't outsource to generic AI — here's why.

Start today, not at launch

The best time to start building in public was when you wrote your first line of code. The second best time is today. You don't need an audience to start — you build one by showing up specifically and consistently. Post the bug you fixed this afternoon. That's the whole beginning.