Build in Public
How to Build in Public When You Have No Audience
Start building in public from zero using a simple loop: join relevant conversations, contribute useful context, show proof, make a bounded ask, and keep a…
By Uriel Bitton · 3 min read
The short answer
You can build in public without an existing audience by starting where your target users already discuss the problem. Contribute useful context first, publish evidence from your own work, invite one specific response, and maintain a durable founder or product history people can inspect after discovering you. Optimize first for relevant conversations, not follower count.
You can build in public with no audience by starting inside conversations that already contain your target users instead of waiting for strangers to discover your posts. Contribute something useful, publish evidence from your own work, invite one specific response, and keep a durable record people can inspect afterward. Your first goal is not followers. It is relevant conversations.
Zero audience changes distribution, not what you should share
Having no followers does not mean you need louder content. You still need useful material: a problem you encountered, a decision you made, something you shipped, an experiment, evidence, or a lesson.
The difference is distribution. If you publish a thoughtful update to an empty account and do nothing else, very few relevant people may ever encounter it. Instead, use a Zero-Audience Loop: conversation → contribution → proof → invitation → durable context.
Start inside conversations that already exist
Find where people who might care about the problem are already talking. A founder building software for finance teams might search for discussions about month-end reporting, reconciliation, forecasting, or spreadsheet workflows. A developer-tool founder should look for technical conversations around the actual problem rather than only following other startup builders.
X explicitly supports joining conversations through replies, and LinkedIn lets members comment and reply to posts. Reddit also allows participation in public communities, although individual communities may restrict promotion and set their own rules.
Do not enter those discussions with “check out my startup.” Answer the question. Add an example. Explain a tradeoff. Share what you learned. Make the contribution useful even if nobody clicks your profile.
Turn your work into proof
Once you are participating in relevant conversations, your own public updates have context.
Three founders told us importing customer data was the first point where onboarding became confusing. We replaced the five-field mapper with automatic column matching. Two edge cases still fail, so that is what we are testing next.
That update shows a problem, a decision, evidence, and an unresolved question. A person discovering you through a reply can now open your profile and see that you are actually working on the problem you were discussing.
Ask for one bounded response
Do not finish every post with “Thoughts?” Ask the person you need for the smallest useful next action.
If you run onboarding for a self-serve SaaS, does this failure mode look familiar?
Looking for two people who import Stripe data weekly to test this workflow.
If you have solved this with Postgres rather than DynamoDB, I would like to compare the tradeoff.
A bounded request helps the right reader recognize that their experience is relevant. Buildside's guide to attracting opportunities while building in public uses the same principle: make the need and next action explicit.
Give discovery somewhere to lead
A social post disappears quickly. Your product history should not.
Buildside's guide to where SaaS founders should build in public recommends separating a durable home from the reach channel. The reach channel helps someone discover you; the durable home gives them enough context to evaluate the founder, product, previous decisions, and current work.
Measure conversations before followers
At the beginning, follower count is a weak operating target. Track whether your public work creates conversations with intended users, product questions, beta-test interest, useful introductions, feedback that changes a decision, and repeat interactions with relevant people.
Ten likes from unrelated founders may feel better than one detailed reply from your target customer, but the second can be more valuable to the product.
Do not manufacture content to keep a streak alive. Do the work, capture what is useful, and distribute it where the surrounding conversation makes it relevant.
When you have no audience, building in public is not about speaking to an empty room until it eventually fills. Start in the rooms where the right people are already talking. Contribute first, show your work, and give interested people a clear path back to what you are building.
Frequently asked questions
Can I build in public with zero followers?
Yes. Use existing conversations and communities as your initial discovery layer rather than depending entirely on your own feed. Contribute useful information first, then give interested people a way to inspect your work.
Should I post every day when I have no audience?
No fixed daily cadence is required. Publish when you have a useful unit such as a decision, experiment, result, lesson, or bounded request, and spend enough time participating where relevant users already talk.
Where should I build in public if I have no audience?
Choose one reach channel where your intended users already discuss the problem and one durable place for your product history. The best reach channel may be X, LinkedIn, Reddit, a technical community, or another niche community depending on the customer.
Should I promote my SaaS in other people's conversations?
Only when it is genuinely relevant and permitted by the platform or community. A useful default is to make the reply valuable without the product link; introduce your product only when it directly helps answer the problem being discussed.
A note from Uriel Bitton
Starting from zero changes distribution, not the quality bar. Join relevant conversations, contribute before asking, show specific work, and make it easy for the right person to understand what you are building next.
Keep building with us
Get practical founder lessons and product updates in your inbox.