How to Build in Public as a SaaS Founder

Quick answer: Build in public by sharing useful decisions, experiments, lessons and verifiable progress on a sustainable cadence. Protect customer data, employee privacy, security details and confidential agreements. Treat public updates as a product-learning and distribution system—not a performance of constant success.

Building in public can create trust, peer relationships, recruiting reach and an archive of expertise. It can also consume the time needed to build and sell. The practice works when each update helps a defined audience and is produced from work you already do.

Choose the audience and purpose

Pick one primary audience:

• potential customers;
• other founders;
• developers or contributors;
• investors or partners;
• future employees.

Then select one purpose: product research, education, distribution, accountability or category leadership. A technical architecture post may attract peers but not buyers. That is fine if peer credibility is the goal.

Use four content pillars

Customer problem

Share anonymized patterns, workflow observations and practical guides. Focus on the problem, not private stories. This pillar attracts the people most likely to need the product.

Product decisions

Explain the trade-off behind a feature, pricing test, onboarding change or technical choice. Include the alternatives and evidence used.

Experiments and results

State the hypothesis, action, timeframe, metric and result. A failed experiment with clear conditions is often more useful than a victory without context.

Founder operations

Show systems for support, planning, launches and focus. Avoid turning every ordinary task into content; publish what is transferable.

A useful update format

Context: We saw that new agency users connected data but did not create a report.
Hypothesis: Starting with a real template would reduce time to first value.
Change: We replaced the blank dashboard with an editable example.
Result: Over the stated sample and period, more users completed the report workflow.
Limitation: Traffic sources changed, so this is directional rather than causal.
Next: We will test whether repeat use improves.

This is more credible than “Activation exploded!” Include numbers only when the sample, timeframe and definition can be explained.

What not to share

• Personal customer information or identifiable support details without permission.
• Private revenue, usage or contract data belonging to customers.
• Credentials, internal endpoints, unpatched vulnerabilities or security controls that increase risk.
• Confidential partner or employee information.
• Screenshots containing personal data.
• Claims about future features that create misleading expectations.
• Metrics selected only because they make the company look larger.

When in doubt, delay and anonymize. Public accountability never overrides privacy or contractual duties.

Turn operating work into content

Create a weekly evidence log:

• decisions made;
• customer questions repeated;
• experiments started or concluded;
• product changes shipped;
• surprising data;
• failure and recovery;
• useful resources discovered.

At the end of the week, select one item that serves the audience. One thoughtful post can be adapted into a short social update, a community answer and a section of a durable article without copying the same promotional caption everywhere.

Tools such as LaunchLog, FoundrList and RankInPublic can be explored on IndieTools for public-building and founder-discovery workflows.

Balance public work and customer work

Use a ratio: for every hour publishing, spend several hours speaking with users, improving the product or distributing directly. Batch writing and use a fixed window. If the content schedule causes missed support or slower learning, reduce the cadence.

A sustainable baseline might be:

• one short weekly experiment update;
• one monthly deep dive;
• one quarterly transparent retrospective;
• ad hoc product updates only when meaningful.

Frequency is less important than continuity and value.

Connect build in public to launch and SEO

Public posts become stronger when organized into durable pages:

• combine repeated pricing lessons into a guide;
• turn launch experiments into a Product Hunt checklist;
• document directory results inside the startup directory distribution guide;
• publish original product data with methodology;
• link product profiles and related educational pages naturally.

This lets the work continue helping people after a social feed moves on. The small-budget SaaS marketing guide explains the wider channel portfolio.

Measure useful outcomes

Track:

Attribution will be incomplete. Ask customers how they first heard of you and which resource influenced the decision.

Handle criticism

Separate factual correction, product feedback, value disagreement and harassment. Correct facts publicly, thank useful feedback, explain trade-offs and disengage from abuse. Do not send followers toward a critic.

If an experiment fails, state what happened and what changes. If a promise changes, update the original post where possible.

A four-week starting plan

Week 1: Publish the problem, audience and current hypothesis.
Week 2: Share one product decision with alternatives and constraints.
Week 3: Publish one experiment result with limitations.
Week 4: Create a durable guide from the recurring questions and link it to the product only where useful.

For a founder starting with no following, pair this practice with how to launch a SaaS without an audience.

Frequently asked questions

Does building in public help sell SaaS?

It can when the content reaches buyers, demonstrates relevant expertise and leads to a credible product path. Founder-audience growth does not automatically equal customer growth.

Do I need to share revenue numbers?

No. Share only metrics that serve the audience and that you can contextualize. Customer privacy and contractual obligations come first.

How often should I post?

Choose a cadence you can maintain without reducing product and customer work. One useful weekly update is enough for many solo founders.

What if competitors copy what I share?

Share principles, learning and non-sensitive decisions while protecting proprietary or security-sensitive details. Execution, customer understanding and trust remain difficult to copy.

Sources and further reading

• Google: Creating helpful, reliable content
• Hacker News Show HN guidelines
• Product Hunt launch guide