Build in public: what to share so launch day has an audience
Build in public means sharing progress, numbers and decisions while you build. What to post in the weeks before launch, where, and what to keep back.
LLaunchScaler·Published ·8 min read
Building in public means sharing how you build your product while you build it: the progress, the numbers, the decisions and the mistakes, posted where your future users can follow along. Done in the weeks before launch, it gives launch day an audience that already knows what the product does and why it exists.
Below is what to share and what to keep back, a posting plan for the eight weeks before launch, the channels that fit, and how to turn followers into a waitlist and then into launch-day visitors.
What does build in public mean?
Build in public is the practice of documenting a product's development openly, usually on social platforms and founder communities, instead of working quietly until launch. The posts are about the work itself: what shipped, what broke, what you decided and why. People who follow along become the first users, testers and supporters.
It works because a launch-day post from a stranger asks for trust it hasn't earned, while a launch-day post from someone people have watched for two months doesn't. Indie Hackers, one of the communities built around the idea, describes itself as a place where founders "share their experiences, give and receive feedback, and rely on each other for support."
It isn't a requirement for a good launch, and it isn't free: it takes time every week and exposes your mistakes. It fits founders who can post consistently and whose buyers read the same places.
What should you share before launch?
Share progress, numbers and decisions, not only screenshots. A screenshot shows that you're working; a number or a decision gives people a reason to care what happens next. The posts that build an audience teach something or invite an opinion, so each one should carry a fact the reader didn't have before.
Type of post
What it contains
Example
Progress
What shipped this week, with a short clip
Questions, answered
What people ask about this
01
What does build in public mean?
It means sharing how you're building a product while you build it: progress, numbers, decisions and mistakes, posted where your future users can follow along. The goal is an audience that already knows the product when you launch.
"Invoices now draft themselves from Stripe payouts. 40 seconds, start to PDF."
Numbers
A metric and what it means
"Waitlist at 312. 41 replied with their use case; 30 are agencies, not freelancers."
Decisions
A choice, the options and why
"Dropping the free plan for a 14-day trial. Here's the math and what I'm unsure about."
Mistakes
What went wrong and the fix
"Signup emails went to spam for a week. SPF was missing. Fixed; here's the record."
Questions
A real choice you want input on
"Two pricing pages. Which one tells you what you'd pay?"
Behind the scenes
How something works under the hood
"Why we render every page on the server instead of in the browser."
Mix them. A feed of only screenshots reads like ads, and a feed of only numbers reads like a spreadsheet. Aim for one post a week that someone would forward to a friend.
What should you keep back?
Keep back anything that belongs to someone else, anything that creates risk, and anything a competitor could use before you ship. Build in public is about your process and lessons; it doesn't require publishing every detail. Share the lesson a private detail taught you, not the detail.
Keep these out of public posts:
Customer names, data or screenshots containing them, unless the customer agreed in writing.
Security details: infrastructure diagrams with real hostnames, how your auth works in detail, vulnerabilities before they're fixed.
Anything under contract or NDA, including a partner's terms.
Exact revenue by customer, or numbers that let people work it out.
A feature you haven't built yet, described in enough detail to be copied first.
Private conversations, even anonymized, if the person could recognize themselves.
If you're unsure about a post, ask whether the person it involves would be comfortable reading it. If not, rewrite it around what you learned.
Where should you build in public?
Post where your future users already read, and adapt each post to the platform rather than pasting the same text everywhere. X and LinkedIn suit most software products; Indie Hackers suits products aimed at founders; Reddit works only in subreddits whose rules allow progress or launch posts.
Channel
Who reads it
What works there
What to watch
X
Developers, founders, early adopters
Short progress posts, clips, numbers, threads on decisions
Post consistently; reply to people who reply
LinkedIn
B2B buyers, operators, your professional network
Longer posts on decisions and lessons, with one image
Write for buyers, not other founders
Indie Hackers
Founders and people starting businesses
Milestone posts, revenue and growth lessons, feedback requests
Give feedback on others' posts, not only your own
Reddit
Specific communities by topic
Answers to existing questions; progress posts where allowed
Each subreddit sets its own self-promotion rule
Your own blog or newsletter
People who chose to follow you
Longer write-ups that you own
Link to it from the short posts
Pick one main channel and one secondary. Posting everywhere weekly is hard to keep up, and a channel you abandon after three weeks looks worse than one you never started. For Reddit specifically, read each subreddit's sidebar and wiki before posting, and disclose that you built the product; the guide on promoting an app on Reddit covers the rules. The guide to launching on Indie Hackers covers that community.
What is a posting plan for the eight weeks before launch?
Spend the first weeks showing the problem and the work, the middle weeks sharing numbers and asking for input, and the last two weeks announcing the date and making the ask. One or two posts a week per channel is enough if each carries a fact. Consistency matters more than volume.
Weeks 8 and 7: the problem. Post why you're building this, what you tried before, and one early screenshot. Put a waitlist link in your profile.
Weeks 6 and 5: the work. Short clips of features as they ship, one decision post a week, and the first waitlist number.
Weeks 4 and 3: the numbers and questions. Share what testers do and where they get stuck. Ask one real question per week, such as pricing or naming.
Week 2: the date. Announce the launch date and what people get for joining the waitlist before it. Schedule your Product Hunt post, which Product Hunt lets you do up to 1 month ahead "so that you can tease it, drive traffic, and collect followers well before your big day."
Week 1: the countdown. Show the finished product, thank the testers publicly, and tell followers exactly what you'll ask of them on the day.
Launch day: one post per platform as each launch goes live, each with the link and the ask.
Keep a simple log of what you posted and which posts sent waitlist signups, so you know which kind to repeat.
How do you turn followers into a waitlist?
Give followers somewhere to go and a reason to go now. Put the waitlist link in your profile and at the end of posts where it fits, tell people what joining gets them, and report the waitlist number as it grows. Followers are rented on someone else's platform; email addresses are yours on launch day.
Make the link measurable: tag it with utm_source, utm_medium and utm_campaign for each channel, which Google Analytics says you should always set when you tag a URL, so you can see whether X or LinkedIn fills the list. Use a reason to join that's specific: early access on a date, a founder discount, or a free setup. And use double opt-in, so the list you email on launch day holds real addresses.
The waitlist landing page guide covers the page itself: the promise, the form, the confirmation email and the tags that let it be found and shared.
What should you ask for on launch day?
Ask people to visit and comment, not to upvote. Product Hunt's rule is explicit: "you cannot ask people directly to upvote your product. Instead, ask them to visit and comment." Hacker News goes further and says it penalizes or bans "submissions, accounts, and sites" that ask for upvotes, and asks you not to solicit comments either.
A launch-day post that works for a build-in-public audience:
One line on what launched, in the words you've used all along.
The link to where it's live, with no tracking parameters on Product Hunt, whose URL field doesn't accept them.
The ask: "Try it, and tell me in the comments what you'd change."
A thank-you to the people who followed along and tested it.
Then spend the day answering. Your followers came because you talked to them for two months; launch day is when they expect you to keep doing it. The SaaS launch strategy shows where these posts sit in the wider launch week.
When should you pay for visibility?
When your audience is still small on launch day, paid placement puts the product in front of people who are already browsing for new products, which your own followers can't do yet. It makes most sense for a week that matters, such as launch week or the week you ship a major update, and only with the placement clearly labelled as paid.
LaunchScaler's Featured placement is sold by the week: the homepage hero at $199 a week (one of three rotating slots every visitor sees, pinned above trending and in the newsletter), the top of your category at $49 a week, or a Spotlight card in the rail at $19 a week, live the moment you buy. Every slot carries a visible Featured badge and is labelled as paid, and you can book 1 to 4 weeks with the start date shown up front. The guide on whether a featured placement is worth it covers when it pays off. If your following is still small in launch week, get featured for that week.
Share what changed this week, the numbers behind it, the decisions you made and why, and what didn't work. Screenshots help, but a post with a number or a decision gives people a reason to follow.
03
What should I not share when building in public?
Keep back customer data, anything under a contract, security details, exact revenue by customer, and plans a competitor could copy before you ship. Share the lesson, not the private detail.
04
Where should I build in public?
Where your future users already read: X and LinkedIn for most software, Indie Hackers for founder audiences, and Reddit only in subreddits whose rules allow progress or launch posts.
05
How do I turn followers into launch-day users?
Link a waitlist in every post, give followers a reason to join now, and email the list on launch day with one link and one ask: visit and comment.
Buying Product Hunt upvotes breaks its rules and can get the product removed and you banned. Bought votes bring no users; paid placements sold openly do.
Bulk directory submission packages list you on 100+ directories they rarely name. What they include, what Google's link spam policy says, and what to ask.
