Building in Public: What to Share and What to Skip
Building in public means sharing the work on your product as you do it: what you shipped, what broke, what you decided and why, and the numbers you’re willing to show. Done well, it can give people a reason to follow a product before they need it, and bring you feedback early. Done badly, it can turn into a feed of vague milestones nobody can check.
This guide covers what’s worth sharing, what to keep private and how to keep it sustainable when you’d rather be building. We run LaunchGP, a launch directory, so we have a stake in makers shipping in the open; near the end we show how its pit stops fit the habit.
Why do makers build in public?
For a small product with no marketing budget, building in public can do a few practical things:
- People who follow the work may become early users. They’ve seen the product grow, so trying it is a small step.
- Feedback arrives before launch day. Someone points out the confusing screen while it’s still cheap to change.
- It keeps you shipping. A weekly update is a small, public deadline.
It isn’t a growth hack, and it doesn’t guarantee an audience. We think it works best as a habit you’d keep even if nobody was watching.
What should you share?
The short version, before the detail:
| Share | Skip |
|---|---|
| What shipped, with a screenshot | Vague milestones |
| What broke and what you changed | Security details before the fix |
| Decisions and the reasoning | Other people’s private messages |
| Numbers you can back up | Rounded-up or unverifiable numbers |
| Questions users asked, with their permission | Customer data |
What shipped
In our view, the most useful post is the simplest: what changed this week, with a screenshot. “Exports now include notes” tells a potential user something; “Big week!” doesn’t.
What broke, and what you did about it
Outages, bugs, a launch that didn’t go the way you hoped. Say what happened and what you changed. People get to see how you handle problems, which is something a landing page can’t show.
Decisions and why
Why you picked this price, why you dropped a feature, why you said no to a request. Other makers may find the reasoning more useful than the result.
Numbers you’re comfortable with
Signups, active users, revenue: only the ones you’re happy to share, and only real ones. If you share revenue, verified is better than a screenshot. On LaunchGP, Endurance places each product in a class by its Stripe MRR, verified with a read-only key, and the product page shows the class rather than the exact figure. How to verify MRR without sharing your Stripe account explains how that works.
What users told you
A question several people asked, a request you’re now building. Ask before quoting anyone, and never share a customer’s details.
What should you keep private?
- Customer data. Names, emails, screenshots with someone else’s information in them.
- Security details. Don’t describe a vulnerability before it’s fixed.
- Other people’s private messages, unless they said you can.
- Numbers you can’t back up. A rounded-up number is still a wrong number.
- Vague milestones. “Huge things coming” says nothing. Share the thing when it ships.
- Posts that are only about you. Give readers something they can learn or use.
How often should you post?
Pick a pace you can keep for a year. Weekly is a reasonable starting point: one post with what shipped, one thing you learned and what’s next. If you can’t keep weekly, every two weeks is fine. In our view, a steady rhythm matters more than volume.
Where should you post?
Wherever the people who’d use your product already are: a social network, a community for your field, your own blog or a newsletter. Your own changelog or blog is the one place you fully control, so keep a copy of each update there and share it outward.
How do updates become a record?
Each update you share is also a record of how the product is moving. On LaunchGP, logging an update in your garage counts as a pit stop in LaunchGP Endurance: you add a version, a line on what shipped and, if you like, a link to the changelog. The car refuels and runs faster for 3 days, and the tank stays full for 14 days after each pit stop, so a product that keeps shipping keeps its pace after its Grand Prix.
It’s the same idea as building in public, with a track to show it. If you haven’t raced yet, how to launch a SaaS without an audience explains how a product gets on the grid.
How do you keep it honest?
One way to keep it sustainable is to share what you’d share with a friend who asked “how’s the product going?” Real numbers, real problems, real progress. If there’s nothing to say this week, say what you’re working on and why it’s taking longer.
When you’re ready to put the work in front of a bigger crowd, get your product on the next grid.
FAQ
Is building in public worth it for a solo maker?
It can be, if you enjoy it and keep it up. It costs time every week, and results vary a lot. Start small: one honest update a week where your users already are.
Should I share my revenue when building in public?
Only if you’re comfortable with it, and only real numbers. Verified figures, or a revenue class like LaunchGP Endurance’s, let you show traction without posting every dollar.
What if a competitor copies what I share?
Some risk is real. Share what you shipped and why, and keep unreleased plans and anything that would hurt you if copied to yourself.
Where should I start building in public?
On the platform where your users already spend time, plus your own changelog. Post what shipped this week and one thing you learned.
How do I keep building in public without burning out?
Pick a pace you can keep for a year, reuse each update across channels, and skip a week rather than post something empty.