How to build in public: what to post every week (with examples)
By Naod Tadele · · 6 min read
Building in public means sharing what you're building while you build it: what shipped, what broke, what you learned and what the numbers look like. Done well, it gets you early users, honest feedback and an audience that roots for you before launch day.
The hard part isn't knowing that you should do it. It's knowing what to post this week, then actually posting it when you'd rather be coding. This guide is the playbook: six kinds of posts that work, examples of each, and a routine that takes about 30 minutes a week.
Why building in public works
- People follow stories, not launches. A product that shows up every week with real progress is easier to trust than one that appears once with a big announcement.
- You get feedback while it's cheap. A question post can save you a week of building the wrong thing.
- It compounds. Every post is a small bet. Most do little; a few bring the users, collaborators and opportunities.
The 6 posts that work (with examples)
Don't post about every commit. Rotate through these six. A good week has three to five of them, and at least one that isn't about a feature.
Feature
Post it when: You shipped something a user would notice.
Tip: Say what changed for the user, not what you refactored. One feature per post.
Nightshift now groups related alerts into one incident. A 3am outage used to be 40 pings. Now it's one timeline you can read in 10 seconds.
Lesson
Post it when: Something was hard, you made a call, or you got it wrong.
Tip: These travel furthest. Be specific about what you believed before and what changed your mind.
I spent 3 days building smarter dedupe rules before a customer said: I don't want fewer alerts, I want to know which one matters. Deleted the branch. Built grouping instead.
Milestone
Post it when: A real number moved: first user, first sale, 100 signups, $1k MRR.
Tip: Use the exact number and add one line of context. Never round up or invent a number.
Nightshift crossed $1,000 MRR. 41 customers. Five months ago it was a weekend script.
Behind the scenes
Post it when: Your process, tools or a normal day would interest someone doing the same thing.
Tip: Show, don't pitch. A screenshot of your setup or messy notes beats a polished announcement.
How I test Nightshift: a tiny script fakes a 3am outage on my own servers every Friday. If I hate the alerts, customers will too.
Question
Post it when: You're genuinely unsure what to build or how to price it.
Tip: Give two concrete options. Replies are the best signal the algorithm gets, and the answers are useful.
Building next for Nightshift and I can't decide: A) incident updates as Slack threads B) a morning email digest Which would you actually use?
Recap
Post it when: End of the week or month.
Tip: Three to five lines with the numbers. It's the post that makes people follow along over time.
Week 12 of Nightshift: - shipped alert grouping - 6 new customers - fixed the timezone bug 3 people reported Next: Slack threads.
A 30-minute weekly routine
- Check in (5 min). Write down what shipped, what was hard, any numbers or user feedback, and what you're unsure about next. Bullet points are fine.
- Pick the moments (5 min). From your commits and notes, choose one or two things users would care about. Skip the refactors and dependency bumps.
- Draft a mix (15 min). One feature, one lesson, one question, plus a milestone or behind-the-scenes post if you have one. Keep each under 280 characters.
- Schedule and forget (5 min). Spread them across the week, one a day at most. Then go back to building.
Mistakes to avoid
- Posting your changelog. "Fixed bug in auth middleware" means nothing to a follower. Say what it changed for users.
- Hype words. "Excited to announce a game-changing…" reads like an ad. Plain and specific wins.
- Only posting wins. Lessons and honest struggles get more replies than launches.
- Going quiet after launch. The weeks after launch are when consistency matters most.
Make it a 30-second habit with Loudcode
I built Loudcode because I kept skipping this routine. It reads your GitHub, asks you the check-in questions above, and hands you a week of posts in exactly this mix: a feature, a lesson, a question, a milestone. You edit what you want and schedule the rest to X. Nothing posts without your approval.
FAQ
How often should I post when building in public?
Three to five times a week is plenty for most solo founders. Consistency matters more than volume: a steady mix of features, lessons and questions beats a burst of posts after a launch.
What if I have nothing to share this week?
You almost always do. A decision you made, a bug that took too long, a user message or a question about what to build next are all posts. Progress on a hard problem counts even if nothing shipped.
Should I share revenue numbers?
If you're comfortable, yes. Real numbers are some of the most engaging posts in the build in public community. Share exact figures or don't share them; never round up.
Is building in public only for X?
No, but X is where most developer and indie founder audiences are today. LinkedIn works well for B2B products, and Bluesky has a growing developer community.