Build in Public
How Building in Public Helps You Get Your First SaaS Customers
Use building in public to create buyer-relevant proof, start customer conversations, and support founder-led sales for your first SaaS customers.
By Uriel Bitton · 4 min read
The short answer
Building in public can help SaaS founders win early customers by making their work discoverable and credible before a sales conversation starts. Share a buyer problem, show real evidence, invite a specific customer type to respond, then handle discovery and conversion personally. Public posting is an acquisition assist, not a substitute for direct early-stage sales.
Building in public can help you get your first SaaS customers when you use public updates to start relevant buyer conversations, not simply collect followers. Share a customer problem, show evidence that you are working on it, invite a specific type of user to respond, then handle the actual sale personally. Your public work gives prospects context; founder-led conversations turn that attention into customers.
Building in public does not replace early sales
The dangerous version of building in public is: post progress, grow an audience, and wait for customers to appear. Early-stage SaaS rarely works that cleanly.
Stripe Atlas’s guidance on getting your first customers explains that founders generally need to actively recruit early customers because young companies do not yet have a repeatable marketing engine feeding them qualified leads. Those customers also help refine the product, positioning, and future sales process.
Building in public is useful because it can make that manual work warmer. A prospect who discovers a useful post can inspect what you are building, how you think about the problem, what you have already shipped, and whether you appear credible before replying to you. The post starts the context. You still close the customer.
Use the Public-to-Customer Loop
1. Start with a buyer problem
A first-customer post should make the intended customer recognize themselves. “Finished our new reporting dashboard today” announces activity. “Three agency owners told me they only discover an unprofitable client after the month closes. I am testing a report that flags the problem earlier” explains who the problem affects and why the work exists.
That matters more than announcing another feature.
2. Show public proof
Give the reader evidence that you are doing real work. Proof could be a workflow you changed, a screenshot with customer-safe data, a failed experiment and what changed afterward, a before-and-after process, or a product decision based on repeated feedback.
Pieter Levels’ account of building Hoodmaps in public documents how he livestreamed development, shared working versions as they appeared, gathered public interaction with the product, and continued distributing the project through Twitter and launch communities.
The useful principle is not to livestream your code. It is to let people inspect progress before asking them to trust the finished product.
3. Invite the right person, not everybody
End the update with a bounded invitation. Instead of “Would love feedback,” try: “If you run a two-to-ten-person agency and review client profitability manually, I would like to show you this workflow.” Now the reader knows whether the request applies to them.
This is where Buildside’s guide to attracting opportunities while building in public becomes useful: public work becomes more actionable when the person you need and the next step are explicit.
4. Move the promising conversation out of the feed
Do not try to complete the entire sale in a public thread. When a relevant person responds, move into a direct conversation. Ask about the existing workflow, understand what is painful, show the smallest relevant part of the product, and help them get to value manually if necessary.
Stripe’s first-customer guidance recommends doing unusually hands-on work early because founders are still learning how the customer buys and how the product should be positioned. Building in public creates the opening. Founder-led sales handles the conversion.
5. Turn customer learning into the next public proof
The loop should improve after every conversation. Suppose five founders respond to a post about onboarding analytics and three say the dashboard is less important than identifying exactly where users abandon setup. That discovery can change both the product and the next public update.
Buffer’s May 26, 2026 WriteStack case study reports that founder Orel Zilberman initially built a different product, contacted early users directly, changed direction after learning their real problem, and later grew WriteStack with a mix that included organic discovery, Google traffic, and his building-in-public content. The case does not isolate building in public as the cause of that growth; it shows how public content can operate alongside direct customer learning and other acquisition channels.
Measure customers, not applause
For first-customer acquisition, track relevant buyer replies, direct customer conversations, demos or product walkthroughs, trial or onboarding starts, and paying customers originating from public work. Likes and followers may increase reach, but they are intermediate signals.
This is especially important when you are starting without an audience. Buildside’s zero-audience building-in-public guide recommends starting inside conversations where your intended users already spend time rather than optimizing first for follower count.
For your next update, do not ask, “What can I post today?” Ask: “What problem did I learn about this week, what proof can I show, and which potential customer should be able to recognize themselves in it?” Publish that. Then talk personally to the people who respond.
Sources
Frequently asked questions
Can building in public actually get SaaS customers?
It can create discovery, credibility, and customer conversations, but customers are not guaranteed. Early founders should still actively identify prospects, speak with them directly, and ask for commitment.
What should I post to attract potential SaaS customers?
Share a problem the intended buyer recognizes, evidence from the work you are doing, what you learned, and one specific invitation for a relevant person to respond. Product announcements without customer context are usually less useful.
Should I build an audience before trying to sell my SaaS?
No. You can participate in existing communities and conversations where your target users already spend time while maintaining a public history of your product. The first goal should be relevant customer conversations rather than a large follower count.
How do I know whether building in public is helping sales?
Track buyer replies, direct conversations, demos, onboarding starts, and customers that originated from public posts or profiles. Followers and engagement can support discovery but should not be confused with customer acquisition.
A note from Uriel Bitton
Building in public is most useful for early customer acquisition when public work creates context for direct founder conversations. Show a real customer problem, prove you are working on it, invite the right person to respond, and then do the unscalable work of helping that person become a customer.
Keep building with us
Get practical founder lessons and product updates in your inbox.