How to Build in Public: Practical Tips for SaaS Founders

The short answer

Build in public by sharing decisions, evidence, lessons, and next steps consistently while screening every update for customer, contractual, commercial, and operational risk.

Build in public by sharing the decisions, evidence, experiments, and lessons behind your SaaS—not every private detail. A useful update helps a specific audience understand the problem, see what you learned, and know whether to reply, try the product, or follow the next step.

Start with the reader, not the milestone

Before writing, name the audience for the update. It might be a potential customer, tester, collaborator, or another founder facing a similar decision.

A post about shipping is weak when it only says what changed. It becomes useful when it explains which problem the change addresses, what tradeoff you considered, and what you will learn next.

Share decisions, evidence, and next steps

The most useful build-in-public updates usually include:

• The problem: What question, friction, or observation are you exploring?

• The decision: What did you choose, reject, or postpone—and why?

• The evidence: What did you actually observe from research, testing, usage, or feedback? Separate facts from interpretation.

• The next step: What will you test next, and what kind of response would help?

• The setback: What did not work, and how did it change your plan?

This structure works even when progress is slow. You do not need a dramatic launch or a polished win to publish something useful.

Use a repeatable update structure

A simple format keeps posts focused:

1. Context: What changed or prompted the decision?

2. Evidence: What did you learn?

3. Decision: What will you do—or not do—now?

4. Invitation: Who should respond, and with what information?

Avoid vague requests such as “Any feedback?” Ask about a specific workflow, assumption, or problem instead.

Set boundaries before you publish

Building in public is not the same as making everything public. Review each update for four types of risk:

• Customer risk: Does it reveal a person, company, or confidential conversation?

• Contractual risk: Could it conflict with an agreement or confidentiality obligation?

• Commercial risk: Does it expose sensitive pricing, pipeline, positioning, or strategy?

• Operational risk: Does it reveal security details, credentials, or internal weaknesses?

If the answer is yes—or unclear—anonymize, generalize, delay, or keep the information private. You can still share the lesson without publishing the identifying details.

Make consistency sustainable

Choose one primary channel where your target users already have relevant conversations. Join those conversations with useful context instead of treating every post as an announcement.

Use a cadence you can maintain without turning posting into a second product. Give interested people a durable place to follow the product, then make each update point toward a clear next step.

If you have no audience, start by answering real questions and showing evidence from your work. Useful participation is a better starting point than trying to manufacture attention.

Measure learning, not just reach

Ask whether the right people responded, whether the discussion produced better product evidence, and whether the update created a relevant opportunity. Follower count can provide context, but it should not decide your roadmap.

Watch for common mistakes: performing transparency with vanity metrics, sharing only wins, oversharing private details, or letting public votes replace customer evidence. The goal is not to appear busy. It is to make the work clearer and the next decision better.

FAQs

Do I need an audience before I start building in public?

1. Start by joining conversations your target users already have. Contribute useful context, show evidence from your work, and give interested people a clear place to follow what happens next.

How much should a SaaS founder share?

Share the reasoning, learning, and direction behind your work, but screen every update for customer, contractual, commercial, and operational risk. Generalize or delay anything sensitive.

What should I post when progress is slow?

Share the constraint, the decision it created, what you learned, and the next experiment. Honest progress does not require turning a delay into a milestone.

Author note

I’d rather publish one honest, useful decision than a stream of polished milestones. My test is simple: does this update help the right person understand the problem, evidence, or next step?

Frequently asked questions

A note from Uriel Bitton

I’d rather publish one honest, useful decision than a stream of polished milestones. The test is whether an update helps the right person understand the problem, evidence, or next step.

Keep building with us

Get practical founder lessons and product updates in your inbox.

Subscribe or Join Buildside.

Keep reading