Build in public: a practical guide for indie makers
What building in public means, what to share and what to keep private, a one-hour weekly routine, an update template and the channels that work for indie makers.
Build in public means sharing the work behind your product while you make it: what you shipped, what broke, what you learned, and sometimes your revenue. For indie makers with no marketing budget, it is one of the few ways to build an audience before launch day.
This guide explains what building in public actually involves, what to share and what to keep private, and gives you a weekly routine that takes about an hour.
In this article10
What building in public is
The idea is older than the hashtag. Shawn Wang's essay Learn in Public argues for a habit of creating "learning exhaust": blog posts, tutorials and answers that others can find, instead of learning quietly. Building in public applies the same habit to a product. Every step you take becomes something people can follow.
Some companies go further and publish their numbers. Buffer runs an open dashboard with monthly active users, MRR, ARPU and ARR, plus links to its shareholder updates. Baremetrics lists Open Startups, companies that share their metrics with everyone. You do not need that level of openness to build in public, but it shows the range.
Why it works for indie makers
- You start launch day with an audience. People who watched you build are the first to try, upvote and share.
- Feedback arrives before you write the wrong feature. A screenshot of a half-built screen gets more honest replies than a finished product.
- Trust. Pieter Levels writes on his blog that he builds his startups, such as Nomads.com, Remote OK and Photo AI, by himself and bootstrapped. Years of sharing that work in public are a big part of why each new product gets attention quickly.
- Accountability. A weekly public update is a deadline nobody sets for you.
What to share
Good build in public posts are specific. "Making progress!" teaches nobody anything. Rotate through these types:
- Shipped: a short clip or screenshot of what changed this week, and why.
- Numbers: signups, active users, MRR, conversion rate. Even small numbers are interesting when they move.
- Decisions: "I removed the free plan, here is why." People love reading trade-offs.
- Mistakes: the bug that cost you a day, the feature nobody used.
- Questions: "Which of these two onboarding screens is clearer?" Questions get replies, and replies teach you.
- Lessons: one thing you would tell yourself a month ago.
If you share revenue, consider proving it. TrustMRR is a database of startup revenues verified through payment providers such as Stripe, and it checks for new data hourly. A verified number carries more weight than a screenshot.
What to keep private
Building in public does not mean sharing everything.
- Customer data. Never show names, emails or private messages without permission.
- Security details. Do not post your stack's weak spots or admin screens.
- Exact acquisition tricks that are easy to copy while they still work, if your edge depends on them.
- Personal finances you are not comfortable defending in the comments.
A good rule: share the process and the results, protect the people and the system.
A weekly routine that takes one hour
Monday, 10 minutes. Post what you plan to ship this week. One sentence, one screenshot.
Wednesday, 15 minutes. Share one thing in progress: a design choice, a question, a bug.
Friday, 20 minutes. Weekly update: what shipped, one number, one lesson. Use the same format every week so followers know what to expect.
Any day, 15 minutes. Reply to people who build similar things. Building in public is a conversation. Accounts that only post and never reply grow slowly.
Once a month, turn the four weekly updates into a longer post on your own blog or on a community like Indie Hackers, where founders share revenue and lessons in detail. That longer post is yours: it is indexed by search engines, and it outlives the social feed.
Example: a weekly update that works
Here is a template you can copy for the Friday post:
Week 6 of building a booking tool for small yoga studios. Shipped: studios can now copy last week's schedule in one click. Number: 14 studios signed up, 9 used it twice or more. Lesson: three studios asked for SMS reminders before I mentioned them. Building that next. Question: would you pay for reminders separately or expect them included?
It works because every line is concrete. The reader learns what the product does, sees real traction, understands a decision, and has an easy reason to reply. Notice what it does not include: no hype words, no "huge week", no list of twenty tiny fixes. Keep updates short enough to read in thirty seconds, and save the detail for the monthly long post.
Where to build in public
| Channel | Best for | Format |
|---|---|---|
| X | Fast feedback, maker network | Short posts, screenshots, clips |
| Indie Hackers | Detailed lessons, revenue milestones | Long posts |
| Your blog or newsletter | Owned audience, search traffic | Monthly recap |
| Reddit communities | Niche users | Questions, honest write-ups |
| B2B buyers | Lessons and decisions |
Pick one main channel and one for long posts. Doing five channels badly is worse than doing two well.
Common mistakes
- Only posting wins. Followers can tell. Mistakes and doubts are what make updates worth reading.
- Talking only to other makers. Founders cheer each other on, but they are rarely your customers. Write some posts for the people who have the problem you solve.
- Vanity numbers. Followers and likes are not progress. Share usage and revenue when you can.
- Stopping after launch. The weeks after launch, with real users, are often the most interesting to follow.
Build in public before your launch
Building in public pays off most on launch day. Start at least four to six weeks before, alongside your pre-launch marketing and a coming soon page that collects emails. When launch day comes, your followers become your early adopters.
And when you are ready to go public, list your product on MegaLaunch and share the listing with the people who followed the build.
Frequently asked questions
What does build in public mean?
Building in public means sharing the process of making a product while you build it: features shipped, mistakes, decisions, and sometimes metrics such as users or revenue, usually on social media, a blog or a community like Indie Hackers.
Do I have to share my revenue to build in public?
No. Revenue updates get attention, but you can build in public by sharing progress, decisions and lessons. If you do share revenue, verified numbers are more credible than screenshots.
How often should I post when building in public?
A fixed weekly rhythm works well: a short plan on Monday, one work-in-progress post midweek and a weekly update on Friday, plus a longer monthly recap.
When should I start building in public before a launch?
Start at least four to six weeks before launch day so you have time to build an audience that will try, share and give feedback on the product when it goes live.
Sources
@matthias_mrcPut it into practice. Launch your product.
A permanent page, a followed link to your site, and makers who vote for what they like.
- Free with a link back to MegaLaunch
- Premium: $9.99 one-time, no backlink needed
Done for you
We submit your product to 100+ dofollow directories.
From one brief, with a report for every directory. No badge needed on your site.
From$99one-time
See the plans
