saas-metrics

The Building in Public Playbook for Indie Hackers

A practical guide to building in public. What to share, where to post, and how to turn transparency into growth for your SaaS.

K

Karel

· 10 min read

Building in public is one of the most effective growth strategies available to indie hackers, and it costs nothing except honesty.

The idea is simple: share your journey openly -- revenue numbers, user counts, wins, and failures -- as you build your product. Done well, it creates accountability, builds an audience, and generates organic traffic that compounds over time.

But most founders either share too little (boring updates nobody engages with) or too much (exposing competitive advantages or customer data). This playbook covers exactly what to share, where, and how to turn transparency into growth.

Why Building in Public Works

Accountability

When you commit publicly to goals -- "I am going to hit EUR 5K MRR by June" -- you are more likely to follow through. The public nature of the commitment adds positive pressure. Your audience becomes a lightweight accountability group that keeps you honest.

Audience Building

Every update you share is content. Every piece of content reaches people. Over months, those people become followers who become email subscribers who become customers. The indie hacker community is uniquely receptive to transparent founder stories because they are building too and want to learn from your experience.

SEO and Organic Discovery

Blog posts about your journey rank for long-tail keywords like "how I grew my SaaS to EUR 10K MRR" or "lessons from my first 100 customers." These attract exactly the kind of people who might use your product -- other founders and early-stage operators.

Trust and Credibility

Sharing revenue numbers and customer counts signals confidence. When a potential customer sees that you openly share your metrics, they trust that you will be transparent about product issues too. In a world of vaporware and inflated claims, authenticity is a differentiator.

Faster Feedback Loops

When you share what you are building, people respond with suggestions, bug reports, and feature requests. Building in public turns your audience into a distributed product team that helps you iterate faster.

What to Share

Revenue and Growth Metrics

This is the most common building-in-public content, and for good reason -- people love numbers.

Share:

  • Monthly or weekly MRR updates
  • Customer count milestones
  • Churn rate and how you are addressing it
  • Revenue growth percentage
  • LTV and ARPU trends

Example update:

March recap: EUR 3,200 MRR (+12% MoM). Added 15 new customers, lost 4. Churn dropped from 6% to 5% after we revamped onboarding. Next goal: EUR 4K MRR by end of April.

If you are not sure how to calculate these metrics, start with the MRR, ARR, and churn guide.

Decisions and Tradeoffs

Share the reasoning behind product decisions, not just the outcomes. "We chose to build feature X instead of feature Y because..." is far more interesting than "We shipped feature X."

Share:

  • Why you chose your tech stack
  • How you decided on pricing tiers
  • Features you considered but killed (and why)
  • Architecture decisions and trade-offs

Failures and Lessons

Failures get more engagement than wins. This is not because people enjoy schadenfreude -- it is because failures contain the lessons everyone wants to learn. A post about "How we lost 20% of our customers in one month" will get 10x the engagement of "We hit a new revenue record."

Share:

  • Launches that flopped (and what you learned)
  • Features nobody used
  • Marketing experiments that failed
  • Pricing mistakes
  • Times you almost gave up

User Stories and Feedback

Share anonymized customer feedback, both positive and negative. "A customer told me they were about to cancel because X, so we built Y" is a compelling story that shows you listen.

One of the most effective building-in-public moments is the honest milestone post. When you share something like "We just crossed EUR 1K MRR -- here is every mistake we made getting here," it resonates because it is real. These posts consistently outperform polished product announcements because the indie hacker community values the journey over the destination. The people who engage with your struggles today become the customers and advocates who champion your product tomorrow.

Where to Share

Not all platforms are equal for building in public. Here is where to focus based on your goals:

Twitter/X

Best for: Real-time updates, short insights, engagement Format: Thread recaps (weekly or monthly), single-tweet updates, screenshot shares Audience: Indie hackers, developers, VCs, tech community

Twitter threads work especially well. A monthly recap thread with 8-10 tweets covering metrics, wins, lessons, and next steps consistently gets strong engagement. Use a hook in the first tweet: "Our SaaS hit EUR 5K MRR this month. Here is what worked and what did not (thread)."

Indie Hackers

Best for: Detailed milestone posts, community feedback, long-form updates Format: Product page updates, community posts, detailed revenue breakdowns Audience: Other indie hackers, potential customers who are also builders

Indie Hackers has a built-in audience of people who genuinely care about your journey. Post milestone updates (EUR 1K MRR, first 100 customers) and participate in community discussions. Cross-link to your blog for deeper dives.

Reddit

Best for: Honest AMAs, tactical posts, community-specific feedback Format: r/SaaS, r/startups, r/Entrepreneur, r/indiehackers posts Audience: Broad tech and business community

Reddit rewards authenticity and punishes self-promotion. Lead with value: share what you learned, include numbers, and mention your product only in context. A post titled "What I learned going from EUR 0 to EUR 3K MRR in 6 months" works. "Check out my new SaaS" does not.

Your Own Blog

Best for: SEO, permanent record, detailed breakdowns Format: Monthly or quarterly recap posts, deep-dive articles Audience: Organic search traffic, existing newsletter subscribers

Your blog is the only platform you own. Twitter could change its algorithm tomorrow, but your blog content is yours forever. Write monthly recap posts and deep-dive articles that rank for long-tail keywords.

If you are pre-launch, building in public pairs perfectly with a waitlist strategy. Share your building journey to drive signups, and use referral mechanics to let your audience help you grow.

Newsletter

Best for: Deeper relationship building, direct communication Format: Weekly or biweekly updates, behind-the-scenes content Audience: Your most engaged followers

A building-in-public newsletter is more intimate than social media. Subscribers opted in, so they want detailed updates. Share things you would not post publicly: revenue screenshots, customer conversations (anonymized), and personal reflections on the founder journey.

What NOT to Share

Transparency has limits. Here is where to draw the line:

Exact Code and Architecture Details

Share your tech stack and high-level architecture. Do not share database schemas, API keys, or proprietary algorithms. "We use PostgreSQL with Row Level Security" is fine. Posting your RLS policies is not.

Security Details

Never share how your authentication works in detail, what security tools you use, or any information that would help an attacker. "We use Supabase Auth" is fine. "Here is how we validate tokens" is not.

Customer Data

Even anonymized, be careful. "A customer in the healthcare space told us..." could identify someone if your customer base is small. When in doubt, ask permission or aggregate multiple customer stories into one.

Exact Financials Beyond Revenue

MRR and customer count are fair game. Your bank balance, personal salary, equity arrangements, and tax details are not. Keep the transparency focused on product and business metrics.

Unreleased Competitive Advantages

If you have a unique approach to a problem that competitors have not figured out, do not explain it in detail. Share the outcome ("Our onboarding converts at 40%") not the method (your exact onboarding flow that took months to optimize).

A common mistake is sharing detailed product roadmaps publicly. When you announce "We are building X, Y, and Z next quarter," you create expectations you may not meet, give competitors a heads-up, and lock yourself into commitments before you have validated them. Share what you shipped and what you learned -- not what you plan to ship. Your audience cares about results and lessons, not promises.

Templates for Consistent Updates

Consistency matters more than brilliance. Use these templates to make sharing easy:

Weekly Tweet Template

This week at [Product]:

  • [Key metric change]
  • [Feature shipped or decision made]
  • [Lesson learned or interesting finding]
  • [What is next]

Monthly Recap Template

[Month] recap for [Product]:

Revenue: EUR [MRR] (+/- [%] MoM) Customers: [count] (+[new] / -[churned]) Key wins: [1-2 bullet points] Key lessons: [1-2 bullet points] Next month: [1-2 goals]

Milestone Post Template

[Product] just hit [milestone].

Here is how we got here:

  • [Timeline: when we started, key inflection points]
  • [What worked: top 2-3 growth channels]
  • [What did not work: top 1-2 failures]
  • [Biggest lesson]
  • [What is next]

Tools for Building in Public

You do not need many tools, but these help:

  • A SaaS metrics dashboard: Automates the numbers so you always have accurate data to share. No more logging into Stripe and doing mental math before every update.
  • A scheduling tool: Buffer, Typefully, or similar. Write your updates in batch and schedule them. This prevents the "I should post an update but I am too busy building" problem.
  • A screenshot tool: Clean screenshots of dashboards, metrics, and milestones make updates more engaging. People scroll past text but stop for charts.
  • A launch scorecard: Before going public with your launch, score your readiness across marketing, product, and community. The Launch Scorecard helps you identify gaps before they become public stumbles.

The Compounding Effect

Building in public is a long game. Your first few updates will get minimal engagement. That is normal. The compounding happens over months:

  • Month 1-3: You are posting into the void. A few likes, maybe a comment or two.
  • Month 3-6: A small group of regular followers starts forming. They engage consistently.
  • Month 6-12: Your updates start getting shared. New followers come from word of mouth.
  • Month 12+: You have a genuine audience. Launch announcements reach thousands. Customer acquisition includes "I have been following you for months and finally need this."

The founders who succeed with building in public are the ones who keep going past month 3 when it feels like nobody is watching. Someone always is.

Getting Started Today

You do not need a plan, a strategy, or a content calendar. You need one post.

  1. Write your first update. Share where your product is today: how many users, how much revenue (even if it is zero), and what you are building next.
  2. Post it on Twitter and one other platform (Indie Hackers or Reddit).
  3. Set a recurring reminder to post weekly. Even a three-sentence update counts.
  4. Link to your blog for longer pieces. Every blog post is an SEO asset that compounds.
  5. Engage with others building in public. Comment on their updates. The community is reciprocal.

The best time to start building in public was when you started building. The second best time is today.

Plan your public launch with IndieBase. Get started free

K

Karel

Founder of IndieBase. Building tools for indie hackers who want real numbers, not vanity metrics.

IndieBase

Share your metrics with confidence

IndieBase auto-generates shareable milestone cards from your real revenue data — perfect for building in public.

Start sharing free

You might also like