What building in public is, and isn't
Building in public is documenting what you're making while you make it. Readers follow the story: what you tried, what worked, what didn't. It suits founders, indie hackers, developers, writers and anyone making something over months.
It isn't a daily highlight reel or a stream of launch announcements. The interesting part is the decisions and the honesty. A post about a failed experiment often lands better than one about a win.
The benefit is compounding trust. People who watched you work through problems for months are more likely to try what you launch, recommend it and forgive early rough edges. You also get feedback early, when it's cheap to act on.
Five formats to rotate
| Format | When | Template |
|---|---|---|
| Weekly update | Every week, same day | Build in public update |
| Milestone | When you hit a number that matters | Milestone tweet |
| Lesson | After a mistake or surprise | Lessons learned thread |
| Feature update | When something ships | Feature update tweet |
| Year or quarter review | End of a period | Year in review thread |
Example posts
- Y
Your name@you
Week 14 building my invoicing app: - Shipped recurring invoices - 9 new paying users (61 total) - Churned 2, both said the same thing: no multi-currency So next week is multi-currency. Hard to argue with the people paying you.
- Y
Your name@you
We're killing our free plan. It was 80% of signups and almost none of our support time went to paying users. That's backwards. Existing free users keep their accounts. New users get a 14-day trial instead. I'll share what happens to signups in a month.
- Y
Your name@you
Spent three weeks building a feature nobody used. The mistake: I asked users “would you use this?” and they said yes. Everyone says yes. Now I ask “how do you handle this today?” If the answer is “I don't,” I don't build it.
- Y
Your name@you
My newsletter passed 1,000 subscribers this morning. It took 14 months. The first 100 took five of them. What changed: I stopped writing about everything and picked one topic. Growth followed the focus, not the frequency.
A cadence you can keep
One weekly update on the same day is the backbone. Followers learn when to expect it. Between updates, post two to four smaller pieces: a screenshot, a lesson, a question. Replying to other builders counts too, and is how many build-in-public accounts find their first readers.
Your first 30 days
| Week | Do this |
|---|---|
| 1 | Post an intro: what you're building, for whom, and why. Pin it. The introduction tweet template helps. |
| 2 | First weekly update. Share one decision you're weighing and ask for input. |
| 3 | Second update, plus one lesson post from something that went wrong. |
| 4 | Third update, plus a short thread on what you've learned in the first month. |
Alongside the posts, reply daily to other people building in public. They're the readers most likely to follow along early, and the community tends to reward people who show up for others.
Common mistakes
- Only posting wins, which reads as marketing rather than a story.
- Updates with no detail: “Great week, lots shipped!” tells readers nothing.
- Going quiet for weeks and then posting a launch.
- Spending more time on posts than on the product.
Handle numbers honestly
- Share bad weeks too. A graph that only goes up stops being believable.
- Say what a number means: “MRR” and “revenue” aren't the same, and nor are “signups” and “users.”
- Don't round up. Readers who later see the real figure stop trusting the rest.
- If you stop sharing a number, say so and why.
If you're a founder or indie hacker, the pages for founders and indie hackers show how Extudio fits a build-in-public routine. Its tweet generator turns your rough notes into posts in your voice, and paid plans can schedule the weekly update into a fixed slot. When it's launch time, read how to launch a product on X.