Build in public: what to share so launch day has an audience

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.

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.

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.

1. 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.
2. Weeks 6 and 5: the work. Short clips of features as they ship, one decision post a week, and the first waitlist number.
3. 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.
4. 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 from tomorrow up to 30 days ahead; it says "Scheduling early gives you time to tell your community the date and get everything ready."
5. 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.
6. 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 try it and comment, not to upvote. Product Hunt's rule is explicit: "Asking people directly to upvote, or running anything that requires or rewards upvotes, breaks Product Hunt's rules." 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:

1. One line on what launched, in the words you've used all along.
2. The link to where it's live.
3. The ask: "Try it, and tell me in the comments what you'd change."
4. 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 sells two placements, each labelled as paid and each for 30 days: a Spotlight card beside every browse page and guide for $19, or one of three slides in the homepage carousel for $79. A run starts no earlier than your launch day, and you see the start date before you pay. Launch Max, $99 once, puts Featured on your launch week and Spotlight on the 30 days from it, together with Premium and a review article published on launch day. The guide on whether a featured placement is worth it covers when it pays off. If your following is still small at launch, get featured for it.