Why Building in Public Often Cannibalizes SaaS Growth and How to Validate Instead

By Michal Baloun, COO at Discury · AI-assisted research, human-edited

Editor's Take — Michal Baloun, COO at Discury

What strikes me when reading these threads is how often founders conflate "visibility" with "validation." I have watched this pattern repeat in the 3720+ quotes we have extracted across 53 analyses at Discury—a founder ships a punchy, public-facing progress update, sees a spike in vanity metrics, and concludes that their product has traction, when the conversion data remains flat. The trap isn't the transparency; it's the feedback loop. Public validation is rarely the same as customer validation; one is a performance for peers, the other is a transaction with a user.

The second trap is the "content-first" bias. Across the 790+ SaaS-founder threads we have indexed at Discury, the most successful founders treat "building in public" as a distribution lever to be pulled only after they have reached a specific revenue or product-market-fit milestone. When a founder starts this process on day one, they often end up optimizing for "shareability" rather than "solvability." It is far easier to write a thread about a new UI component than it is to build a robust data-integration pipeline that actually saves a client ten hours a week.

*If I were starting a B2B SaaS motion today, I would treat building in public as a secondary activity. I would spend the first three months in deep, private discovery. The founders in this sample invert this order, and the threads we monitor amplify that inversion because "how I grew my audience" is inherently more shareable than "how I spent six months interviewing 100 enterprise security engineers."

The Operational Tax of Building in Public and Building Public Trust

Content research, scheduling, and analytics demand a commitment that rivals a full-time marketing position. u/barrell, in one HN discussion on building in public, describes the transition into indie hacking as a realization that audience growth requires a full-time workload of spreadsheets, targeting, and drafting. This operational overhead often forces developers to rely on generic checklists rather than original strategy. In one StackOverflow audit of launch best practices, contributors identified 71 different checklist items—a distraction from the core product features that actually drive long-term retention.

Revenue Exceptions: Building in Public vs. Building Public Records

Building in public can yield massive returns, but typically only when the founder has already solved the "cold start" problem or possesses a unique, original IP. u/buf, in a Farewell to Building in Public thread, reports $800k in annual revenue across two SaaS companies. This specific case highlights that the "moat" was not the public building strategy, but the social marketplace nature of the product, which is notoriously difficult for copycats to replicate. u/majani, in the same HN discussion, corroborates this, noting that a strong moat or original IP like Minecraft is necessary to survive the copycats that inevitably appear once a product gains public visibility.

Technical Moats vs. Building in Public Visibility

Lume, a tool for generating custom data integrations, shows how a focus on deep technical problems can bypass the need for public-facing engagement. u/nmachado, in a Launch HN thread for Lume, describes how the team used GPT-4 and rule-based methods to solve the manual overhead of data transformation. This technical approach achieved a 10x efficiency gain for their users, providing a defensible moat that public updates cannot replicate. u/Avicebron, in the same HN discussion, emphasizes that the accuracy of these transformations is the primary driver of value, not the founder's social presence.

Why Technical Integrations Outperform Building in Public

Axolo, a bidirectional GitHub-Slack integration, illustrates the importance of solving a specific, recurring pain point rather than general audience building. u/arthurcoudouy, in a Launch HN thread for Axolo, notes that the team talked to over 100 companies to validate the specific workflow disruption caused by messy Slack communication during code reviews. u/jrowley, in the same HN discussion, validates this value proposition, noting that the reduction in irrelevant notifications is a clear, quantifiable benefit for engineering teams. This targeted problem-solving approach is a far more effective distribution channel than the generalized "building in public" updates that often lack a clear target audience.

M3O: Building in Public vs. Building Public Policy

M3O, a universal public API interface, highlights the risks of abstraction as a product feature. u/asim, in a Show HN thread for M3O, discusses the goal of simplifying common API use cases like SMS and email into simple building blocks. u/RedShift1, in the same HN discussion, suggests that the real value lies in supporting standards like GraphQL, which would allow developers to maintain a single endpoint rather than stitching together multiple microservices. This case shows that while public building can attract initial attention, productivity is driven by technical standards and interoperability, not just the "building in public" label.

Conclusion: How to Validate Without Building in Public

Building in public is a tactic, not a strategy. If your conversion rate from social engagement to paying customers remains stagnant, the current distribution model is likely failing.

1. Problem Validation: Conduct 50 manual interviews with potential users before writing a single public post. If you cannot find 50 people willing to discuss the problem for 15 minutes, public posting will not save the business.
2. Moat Assessment: Evaluate your product's technical complexity. If the product is a simple wrapper or UI, public building will invite copycats. If it is high-scale, like the security lake platform Matano, focus on technical documentation and AWS-native integration (HN discussion on Matano).
3. Metric Hygiene: Track "trial-to-paid" conversion, not "follower-to-visitor" traffic. If the former is low, the issue is product-market fit, not your social media cadence.
4. Outreach Cadence: Dedicate 80% of your time to direct, private outreach and 20% to public updates. If the outreach is not yielding meetings, pause all public building until the value proposition is refined.

Data Sources for Building in Public Analysis

This analysis draws on eight HN threads (the ones cited inline above). Threads were surfaced via Discury's cross-subreddit monitoring.

discury.io