The Build in Public Playbook for SaaS Founders

You think building in public means tweeting your Stripe MRR every hour. It doesn't. This isn't a guide to vanity metrics, it's a build in public playbook designed to get your first 100 die-hard fans and customers before you've shipped a single line of production code.

What "Build in Public" Actually Means (and What It Isn't)

Let's get this straight. Building in public isn't just marketing. It's a product development methodology. It’s about co-creating your product with your future customers, in the open. You’re not just broadcasting your progress, you’re inviting people into the workshop.

Most founders get this wrong. They think it's a performance. They polish their updates, hide the messy parts, and celebrate every new follower like it's a new paying customer. That's "marketing in public," and it’s a recipe for building a weak product with a shallow audience. True building in public is messy. It's showing the ugly Figma mockups. It’s admitting you spent a week on a feature that turned out to be a dead end. It’s sharing a screenshot of a confusing user interface and asking, "What am I getting wrong here?"

My strong opinion is this: if your process feels more like writing a press release than a lab notebook, you're doing it wrong. The goal isn't applause. The goal is signal. You want the brutal, honest feedback from the ten people who feel your target user's pain so acutely they'd use a half-broken Google Sheet to solve it. Everything else is a distraction.

This approach has two huge benefits for an early team.

1. It de-risks your product. You're validating every step. You stop wasting months building something nobody wants because you’re constantly checking the map with your future users.
2. It builds an audience of buyers, not just followers. The people who stick with you through the messy middle are deeply invested. They feel a sense of ownership. When you finally launch, they don’t just buy, they become your first evangelists.

So forget the leaderboards and the follower counts. The real work is quieter, smaller, and a thousand times more valuable.

The "Audience-First" Flywheel: My Framework for Starting

Starting from zero is the hardest part. No audience, no product, just an idea. Where do you even begin? You start by finding the pain, not by pitching your solution.

I call this the Audience-First Flywheel. It’s a simple four-step loop that you can run over and over.

1. Find the Pain. Your idea probably stems from a problem you have yourself. That's a good start. But you need to confirm others share it. The pain has to be specific. Not "project management is hard," but "I can't get my freelance clients to consistently use my Basecamp project and it's costing me hours in follow-up emails."
2. Find the Watering Hole. Where do people who feel this specific pain gather online? It's almost never Twitter. It’s a subreddit like r/freelance, a specific Slack community for agency owners, or a niche forum for accountants. Find the place where they are already talking about their problems. You need to go to them.
3. Share Learnings, Not Solutions. Do not show up and post "Hey guys, I'm building an app for this!" You will be ignored or banned. Instead, you become a researcher and share what you learn. Post things like, "I've been struggling to onboard freelance clients to my PM tool. I made a checklist that seems to be helping, thought I'd share." Or, "I've tried Asana, Trello, and Monday for this. Here's a quick breakdown of where each one falls short for client-facing work." You give value first. You document your research in public.
4. Invite Collaboration. After you've established yourself as a helpful member of the community, people will start coming to you. You'll get DMs. People will reply to your posts with their own hacks. Now you can make the move. You can say, "A few of you seem to have this exact problem. I'm thinking of building a small tool to solve just this. I'm starting with a simple prototype, would anyone want to see it and give me brutally honest feedback?"

This flywheel builds momentum. Each cycle gets you more insights, more conversations, and more people who are now invested in your success. You aren't selling a product. You're recruiting a build team. And it's from this small, passionate group that your first 10, then 50, then 100 customers will come.

Your Build in Public Channel Isn't Twitter (At First)

Every founder I talk to thinks they need to start on Twitter. It's where all the action is, right? Wrong. For an early-stage founder with no product and no audience, Twitter is a screaming void. Your thoughtful thread about user research will get three likes (one of which is your mom) and you'll get discouraged.

Here's the truth: your initial channel should be a high-signal, low-volume environment. You're looking for depth, not reach. A single, thoughtful conversation in a niche subreddit is worth more than 10,000 impressions on Twitter.

The goal is to find your "founding community." This is a small group of people (think 5-20) who feel the pain you're solving most acutely. Your first channel should be the place where these people already live.

• Is your product for developers? Look at Hacker News, specific subreddits (r/golang, r/devops), or a niche Discord server.
• Is it for designers? Try communities on Figma, Designer Hangout, or even specific Behance comment sections.
• Is it for writers? Substack comment sections, r/writing, or The Freelance Writer's Den are good places to start.

Once you’re in the right place, you don't sell. You contribute. Your goal is to become a known, helpful voice on one single topic. The topic of the problem you solve.

Here’s a script you can adapt for a post in one of these communities. Notice it's all about the problem and asking for insight, not promoting a solution.

Subject: How are you all handling [specific, painful task]?

Hey everyone,

I've been spending way too much time manually transcribing customer interviews and then trying to find key themes. My current process is running audio through an auto-transcriber, cleaning it up, and then copy-pasting notes into a spreadsheet. It feels clunky and takes hours.

I'm curious how other PMs or founders here are tackling this. What's your workflow? Have you found any tools that actually work for finding patterns across multiple interviews?

Just trying to figure out a better way. Thanks.

This post is valuable on its own. It starts a conversation. It surfaces other people with the same problem. And it positions you as someone who is thoughtfully exploring the problem space. From the replies to this one post, you can find your first 5 people for a feedback group. That's your real start.

For founders looking to level up their community-building and teaching skills, investing in cohort-based courses can be a great way to learn from peers who have successfully built audiences from scratch.

Only later, once you have a small but rabid fanbase, a working product, and some real results, does a broadcast medium like Twitter become powerful. Then, you can use it to amplify the stories and wins of your early customers. But don't start there.

What to Share When You Have Nothing to Show

This is the founder's paradox. You need to build in public to get feedback, but you have nothing to show yet. So what do you share? Pictures of your laptop? Mugs of coffee?

No. You share your thinking. You document your process. People are just as interested in the 'how' and 'why' as they are in the 'what'. You have a ton of assets, you just don't see them as assets yet.

Here’s a list of things you can and should share in the earliest days:

• Your Research: Did you just read a great article about your industry? Share the link and your top three takeaways. Better yet, share something you disagreed with. Start a discussion.
• Your Questions: Post the big, open questions you're wrestling with. "I'm trying to decide between a usage-based pricing model and a flat-rate subscription for my future tool. What are the pros and cons I'm missing?"
• Snippets of User Interviews: With permission, share anonymized quotes that highlight the user's pain. For example: "Just got off a call with a potential user. She said, 'I spend the first hour of every Monday just chasing down status updates.' That really stuck with me." This makes the problem real and relatable. If you're struggling to pull these out, a dedicated tool like a customer interview transcription service can help you find these golden nuggets faster.
• Your 'Napkin' Sketches: Take a picture of your notebook. Share the first rough flow you drew. It shows you're in the messy beginning, which makes it easier for others to give input. A polished design is intimidating; a messy sketch is an invitation.
• Low-Fidelity Mockups: Use a tool like Whimsical or even just Google Slides to create wireframes. Record a 2-minute Loom video walking through the flow and asking for specific feedback. "Does this navigation make sense? What would you expect to happen when you click this button?"
• Failed Ideas: This is incredibly powerful. Share a feature you thought was brilliant, prototyped, and then killed. Explain why. "I was convinced we needed a built-in chat function. But after talking to 5 people, I realized they all just want to stay in Slack. So, I'm scrapping the idea and focusing on a better Slack integration instead." This builds immense trust. It shows you listen and aren't afraid to be wrong.
• Your Tiny Wins: Did you write your first line of code? Set up your database schema? Get your first waitlist signup? Share it. Don't frame it as a massive victory. Frame it as one small step forward. "Week 1 of building: I have a landing page and a database that can accept an email. It's not much, but it's a start!"

The key is to shift your mindset from "I need to show a finished product" to "I need to show my work." Your work is the research, the thinking, the mistakes, and the learning. That's the most valuable stuff you have at this stage.

The Practical Build in Public Playbook: A Week-by-Week Guide

Theory is nice. A plan is better. Here’s a tactical, 8-week plan to get you from zero to an MVP with a built-in group of beta testers. This is the exact build in public playbook I’d follow if I were starting a new SaaS today.

Weeks 1-2: The Lurker Phase

Your only job is to listen. Identify the one or two "watering holes" where your ideal customers hang out. Join them. Say nothing.

• Action: Read every single post. Pay attention to the language they use. What are the recurring complaints? What hacks or workarounds do people share? Create a document and just copy and paste phrases, questions, and pain points. Your goal is to develop empathy and learn to speak your customers' language.
• Public Output: None. You are in stealth-research mode.

Weeks 3-4: The Contributor Phase

Now you can start talking. Your goal is to be helpful, not to be a founder. Answer questions you feel qualified to answer. Ask clarifying questions on other people's posts. Share a resource you found.

• Action: Make one helpful comment per day. Write your first "Share Learnings, Not Solutions" post (like the template from before) towards the end of week 4.
• Public Output: A handful of helpful comments and one thoughtful post seeking insight into a problem.

Weeks 5-6: The Invitation Phase

By now, you should have had a few DMs or interesting replies. You've identified 5-10 people who really, really feel the pain. It's time to make your move.

• Action: Reach out to these individuals personally. Say, "Hey, thanks for your thoughts on my post. It seems like we have the exact same problem. I'm starting to build a tiny tool to solve it. Would you be open to looking at some super early mockups and telling me what you think?" Set up 15-minute calls. Separately, create a simple landing page with an email form for your "Design Partner Program."
• Public Output: A link to your new landing page, shared in the context of your research. "Thanks to everyone's feedback, I'm exploring a solution to [the problem]. If you want to follow along and be part of the build process, I'm gathering a small group of design partners here: [link]."

Weeks 7-8: The Co-Creation Phase

You should now have a small group of 10-20 people on an email list or in a private Slack channel. This is your founding community. You are now building with them, not for them.

• Action: Start building the most minimal version of your product. Send updates to your group every 2-3 days. Share Loom videos of the UI as it comes together. Ask for their feedback on everything: copy, button placement, colors, the core workflow. Give them access to the staging environment as soon as it's remotely usable.
• Public Output: Share sanitized, high-level updates with your broader public audience. "This week, our design partners helped us realize our initial navigation was way too confusing. Here's a before-and-after based on their feedback. So grateful for their brutal honesty!"

After these 8 weeks, you won't just have an MVP. You'll have an MVP that a group of target users has already validated and helped shape. And you'll have your first paying customers ready to go on day one.

What Not to Share: Where Founders Go Wrong

Building in public can backfire if you don't have good judgment. Sharing becomes a performance, and the feedback loop breaks. Here's what doesn't work and what you should avoid sharing.

Don't Share Uncontextualized Numbers. Tweeting "Just hit 100 users!" is meaningless. Is that 100 free users who clicked a link once? Or 100 paid users with 90% retention? Raw numbers without context are vanity. Instead, share the story behind the number. "We just hit 100 free beta users. The most interesting part? 30% of them came from a single blog comment I left two months ago. A good reminder that early traction is weird and unscalable."

Don't Share Only the Wins. This is the biggest trap. A feed full of wins makes you look successful, but it makes you unrelatable. It intimidates potential users from giving you critical feedback because they assume you've got it all figured out. More importantly, it attracts the wrong kind of followers: people who want to emulate your success, not people who want to use your product. Share your bugs. Share your bad sales calls. Share your doubts. Trust skyrockets when you're transparent about the struggle.

Don't Share Sensitive Customer Data. This should be obvious, but I've seen it happen. Never share a customer's name, company, or specific data without their explicit, written permission. You can share anonymized, aggregated data or high-level themes, but customer privacy is sacred. Breaking that trust will kill your company before it even starts.

Don't Argue With Feedback. The purpose of this entire playbook is to solicit feedback. When you get it, your job is to say "Thank you" and listen. Even if you think the feedback is wrong. Don't get defensive. Don't write a five-paragraph essay explaining why your original design was actually correct. Ask clarifying questions: "That's interesting, can you tell me more about why you feel that way?" Remember, you don't have to act on all feedback. But you do have to hear it. Arguing in public tells everyone else that their feedback isn't welcome.

Don't Share Your Exact Product Roadmap (With Dates). It's great to share what you're thinking about building next and ask for feedback on priorities. It's a terrible idea to publish a gantt chart with deadlines. As an early-stage startup, your priorities will change weekly. Tying yourself to a public roadmap you can't possibly keep is a recipe for disappointing your users and feeling constantly behind. Share direction, not deadlines.

Think of it like this: share the process, not the secrets. The process of learning, building, and iterating is what creates connection and provides value. Your secret sauce, sensitive company financials, and customer data should stay private.

Measuring Success: The Metrics That Actually Matter

You're putting all this effort into building in public. How do you know if it's working? Likes and retweets aren't the answer. They're candy. They feel good for a second but provide no real nutrition.

Here are the metrics that actually show your build in public efforts are paying off. These are the numbers you should track on your own private dashboard.

1. High-Intent Conversations per Week. This is your lead metric. How many DMs, emails, or replies did you get this week that contained a specific question or piece of feedback about the problem you're solving? A DM that says "Cool project!" is worth zero. A DM that says "I have this problem too, have you considered how you'll handle X?" is worth one. Aim for 5-10 of these per week in the early days.

2. Design Partner Waitlist Signups. This is the number of people who have explicitly raised their hand to say, "Yes, I want to be involved." This is your single most important list. It's more valuable than a 10,000-person newsletter of passive followers. Track its growth, but more importantly, track its quality.

3. Conversation-to-Partner Ratio. Of the people you have a high-intent conversation with, what percentage agree to join your design partner program? A high ratio means your problem description is resonating and you're talking to the right people. If this is low, you either have the wrong audience or your pitch is off.

4. Feedback Implementation Rate. How many pieces of feedback from your design partners did you actually ship in the product? This shows you're closing the loop. You can even share this metric publicly: "In our first month of beta, we shipped 17 changes that came directly from user feedback."

5. Partner-to-Customer Conversion Rate. This is the ultimate test. When you finally launch and ask for a credit card, how many of your design partners become paying customers? A healthy number is north of 50%. If it's 80% or 90%, you've built something truly indispensable. A low number here is a major red flag that you solved a "nice-to-have" problem, not a "hair-on-fire" one.

You can track these qualitative and quantitative metrics on a simple spreadsheet or a purpose-built SaaS metrics dashboard. The key is to focus on engagement and commitment, not eyeballs and applause. Success isn't a big audience. It's a small, committed group of people who are helping you build their favorite future tool.

If you do nothing else this week:

1. Find one online community where your ideal customer spends their time. Just one.
2. Write (but don't post yet) one short post sharing something you learned this week about their biggest problem.
3. Find one person in that community who seems sharp and DM them one specific question about how they handle that problem.