Build in Public
How Building in Public Creates Distribution Before Your Startup Launches
Build distribution before your SaaS launch using public problem signals, product proof, durable follow paths, and interested people you can re-engage.
By Uriel Bitton · 4 min read
The short answer
Building in public creates pre-launch distribution when repeated useful updates make relevant people familiar with the problem and product before launch day. Founders should build four assets: clear problem signals, public proof of progress, a durable place to follow the product, and a launch bridge made of people who have shown real interest. A large follower count is not required, and public attention does not guarantee customers.
Building in public can create distribution before launch by making potential users familiar with the problem, the founder, and the product while it is still being built. The goal is not to collect the largest possible audience. It is to make launch day a continuation of existing attention instead of the first request for it. Build four things before launch: problem recognition, public proof, a durable return path, and permission to contact interested people again.
Launch day should not be your introduction
A cold launch asks strangers to understand a new problem, trust an unknown founder, evaluate a product, and take action at the same moment. Building in public separates those jobs over time.
Someone might first encounter a post about the problem. Weeks later they see a product decision. Then a demo. Then a lesson from something that failed. By launch day, the product is new, but the story is not.
Product Hunt's official before-launch guidance recommends joining its community well ahead of launch—three months or more when practical—and building a presence rather than arriving only when you need attention. Its promotion guidance similarly warns against waiting until launch day to start creating interest. That is the basic distribution advantage: recognition compounds before the announcement.
Build the Pre-Launch Distribution Stack
1. Publish problem signals
Start before you have impressive product screenshots. Share specific observations about the problem you are solving: a workflow that keeps breaking, a tradeoff customers face, an assumption you are investigating, or a decision you changed after learning something.
The reader should be able to recognize the problem without caring yet about your product. This is different from announcing, “I am building an AI tool for agencies.” A useful problem signal sounds more like: “Three agency owners showed me the same spreadsheet they rebuild every Friday because their reporting software cannot separate project margin from team utilization.” Now the right reader has a reason to pay attention.
2. Turn product work into public proof
Once the product starts taking shape, show evidence that the idea is becoming real.
Pieter Levels documented Hoodmaps from its first lines of code, livestreamed the build, put an early working version online, and had people drawing on the product by the second day. His account later documents the project reaching the front page of Reddit and more than 300,000 users. That is an unusually successful example, not a typical expected result, but the mechanism is useful: people could interact with progress before the final launch story existed.
You do not need to livestream development. Show enough proof that interested people can see movement: a working workflow, screenshot, small demo, rejected design, customer-safe result, or decision with evidence.
Buildside's guide to building in public with no audience explains why this proof matters: someone discovering you through a conversation needs somewhere to verify that you are genuinely working on the problem.
3. Give interest somewhere to return
Social reach is temporary. Pre-launch distribution needs memory. Give interested people one durable destination: a product page, founder profile, waitlist, newsletter, or public build history. The purpose is not to force an email signup after every post. It is to prevent each useful interaction from resetting to zero.
Paynter Jacket Co. provides a clear non-SaaS example of the mechanism. Buffer's case study reports that its founders discussed jackets and shared the production process before making their first product. They had roughly 600 followers by their first launch, and the first batch sold out quickly. Their audience was small by social-media standards, but it had followed the product's creation closely.
4. Build a launch bridge
Before launch, identify the people who have moved from passive attention to visible interest.
Joined the waitlist.
Repeatedly replied to updates.
Asked when the product would be available.
Tried an early version.
Requested a demo or subscribed to product updates.
Those signals create your launch bridge. When launch day arrives, you are not asking an anonymous audience to care. You are returning to people who already showed some reason to care.
Product Hunt's launch-promotion guidance makes the same distinction: makers should build authentic community beforehand and then let communities where they have already been active know when the launch goes live.
Do not confuse followers with distribution
A follower count is not the stack. Before launch, track signals closer to future action: relevant repeat commenters, product-page visits, waitlist signups, demo requests, direct conversations, people asking for access, and referrals from existing followers.
Buildside's broader visibility and distribution guide recommends measuring verifiable signals such as visits, replies, conversations, demos, and signups rather than assuming reach equals progress.
For your next four weeks, do not ask how much content you can publish. Ask whether each week adds something to the stack: a clearer problem signal, stronger proof, another return path, or another person you can legitimately invite back when the product launches.
That is how building in public turns launch day from a cold announcement into the next step in a conversation already underway.
Sources
Frequently asked questions
Should I start building in public before my SaaS is usable?
Yes, if you have something useful to share about the problem, research, decisions, or work in progress. You do not need a finished interface, but avoid pretending an idea is more developed than it is.
Do I need a big audience before launching my SaaS?
No. A smaller group of relevant people who repeatedly engage, join a waitlist, request access, or follow the product can be more useful than a large unrelated audience.
What should I post before my product is ready?
Share customer-safe problem observations, decisions, experiments, screenshots, demos, tradeoffs, failures, and what you are testing next. The update should teach or show something even if the reader never signs up.
How do I know whether I have distribution before launch?
Look for repeat interaction from relevant people, product-page visits, waitlist signups, requests for access, demos, direct conversations, and referrals. Followers and impressions can support reach, but they are weaker evidence of launch readiness.
A note from Uriel Bitton
Launch day should be the next step in a conversation, not the first time anyone hears about the product. I want public updates to create recognition and useful relationships while the product is being built, so there is already somewhere for launch attention to come from.
Keep building with us
Get practical founder lessons and product updates in your inbox.