What should SaaS founders share while building in public?
Use practical SaaS update formats for decisions, experiments, failures, milestones, launches, and feedback while protecting sensitive information.
Direct answer
The short version
SaaS founders should share the customer-safe problem, decision, experiment, evidence, tradeoff, lesson, and next step. Useful updates include decision logs, failed tests, bounded metrics, product changes, launch context, and specific requests. Remove customer identities, credentials, private conversations, sensitive architecture, negotiations, and unsupported conclusions. Specific context makes an update useful; total disclosure is neither required nor wise.[1][2][3][4][5]
Compare every build-in-public platformUpdate format library
Six updates that contain a decision—not just an announcement
Use the format that matches the work. Every update should give the reader context, evidence, and a reason the next step follows.
| Format | Include | Leave out | Useful closing |
|---|---|---|---|
| Decision log | Constraint, options, tradeoff, choice, and evidence needed | A false claim that the choice is proven | What risk would you test first? |
| Experiment | Hypothesis, segment, method, denominator, window, result, confounders | A percentage with no base or selective time window | Which alternative explanation should we check? |
| Failure | Expected behavior, observed failure, cause if known, repair, prevention | Customer blame or a lesson invented before the cause is clear | What safeguard has worked for you? |
| Milestone | Starting point, time period, what changed, contributors, next constraint | A vanity number presented as universal success | The next bottleneck is… |
| Product change | User task, before state, change, screenshot, limitation, availability | Sensitive customer data or an unreleased promise | Try this task and tell us where it breaks. |
| Bounded request | Ideal participant, exact task, commitment, timing, exchange, decision | “Any feedback?” or a hidden sales pitch | We need five people who… |
Swipe the comparison sideways to see every column.
The usefulness test
Give the reader enough context to disagree intelligently
“We improved onboarding” cannot be inspected. “Three of five new testers missed the workspace step, so we moved it into the first-run task; the next test checks whether completion improves” exposes the task, denominator, observation, decision, and uncertainty without exposing a customer.
Specificity does not mean publishing everything. It means selecting the minimum context needed to understand why the conclusion follows.
Redaction pass
Remove risk before improving the prose
- Customer names, logos, messages, screenshots, identifiers, and data without explicit approval.
- Credentials, tokens, security controls, exploit paths, sensitive logs, and incident details.
- Private employee or collaborator information and conversations.
- Contract terms, negotiations, roadmap commitments, unreleased competitive details, and non-public financial information.
- Metrics without the denominator, segment, time window, or context needed to interpret them.
- Claims of causation when the evidence only shows a sequence or correlation.
Format follows platform
Keep the evidence stable while changing the presentation
A shipping task belongs naturally on WIP, a technical explanation can become a DEV article, a professional operating lesson can fit LinkedIn, and a concise observation can start a conversation on X. Preserve the source decision and adapt the frame; do not invent a different lesson for every channel.[5][4][3][6]
Final check
Read the update as a customer, competitor, and stranger
Customer
Could someone identify a person, company, account, or private problem that was not approved for publication?
Competitor
Does the post reveal a tactic, weakness, negotiation, or unreleased direction whose disclosure creates avoidable harm?
Stranger
Can a reader understand the problem, evidence, and uncertainty without knowing the entire backstory?
Future you
Will this still be accurate when separated from today's excitement, and can you explain why the decision changed later?
Methodology and disclosure
How this guide was made
The formats are designed around inspectable product work and the public publishing surfaces documented by Buildside, X, LinkedIn, DEV, WIP, and founder communities. The privacy rules are conservative editorial safeguards, not legal advice.
Buildside publishes this guide and appears where it fits the stated job. Platform facts come from linked official sources; recommendations and workflows are Buildside's editorial assessment.
Official sources checked . Features, access, and policies can change.
Official and first-party sources
- [1] Public founder updates
Public, source-level founder progress, experiments, lessons, launches, and requests.
- [2] Types of posts on X
General posts, longer posts, replies, mentions, reposts, and where they appear.
- [3] Post and share updates on LinkedIn
Post length, audiences, comment controls, formats, events, polls, documents, and scheduling.
- [4] Writing, editing and scheduling on DEV
Editor, drafts, scheduling, series, RSS imports, canonical links, analytics, and ownership.
- [5] WIP Help and Getting Started
Completed to-dos, timelines, profiles, projects, streaks, privacy, posting methods, collaborators, and integrations.
- [6] How to post on X
Standard posts, media, drafts, scheduling, and Premium longer posts.
FAQ
Questions founders ask next
Should SaaS founders share revenue publicly?
Only when the founder intentionally accepts the consequences and the number is necessary to the lesson. A bounded metric with segment, denominator, and time window is often more useful than an isolated revenue figure.
Is it okay to share failed experiments?
Yes, when the founder distinguishes expectation, observation, cause, uncertainty, and next step. Do not blame customers or turn an unclear result into a confident lesson.
What should founders never share?
Do not publish customer or employee private information, credentials, sensitive security details, private conversations, negotiations, unreleased commitments, or financial information that was not intentionally approved.
How long should a build-in-public update be?
Long enough to make the decision and evidence understandable, and no longer. There is no useful universal word count; the platform's native format and complexity of the evidence should determine length.
Continue the decision
Related build-in-public guides
Building a SaaS in public
How to build a SaaS in public without turning it into a performance
Build a SaaS in public by documenting specific decisions, evidence, progress, and lessons where relevant people can respond. Keep one durable product history, distribute selected lessons in an audience-native channel, and close the loop by explaining what changed. Protect customer, security, commercial, and personal information, and measure useful conversations and product actions separately from public engagement.
Best build-in-public sites
The best build-in-public sites by publishing format
The best build-in-public site depends on what you can publish well. Buildside fits connected SaaS progress; WIP fits daily completed-task logs; Indie Hackers fits founder discussion; DEV fits durable technical articles; X fits short real-time observations; and LinkedIn fits professional lessons. Choose the native format you can sustain, then keep the full product context in one durable place.
Build in public for B2B SaaS
Build in public for B2B SaaS without performing for founders
B2B SaaS founders should build in public around the buyer's work, not a daily founder diary. Share customer-safe decisions, workflow insights, tradeoffs, and evidence where the target role participates—often LinkedIn, a niche community, or a technical channel—while keeping one durable product history. Measure relevant conversations, design partners, product questions, and qualified actions rather than founder applause.
Inspect the relevant platforms
Keep the public journey connected
Give useful progress a durable home.
Create a founder profile, connect your SaaS product, publish the evidence behind the work, and make the next useful action clear.
Join Buildside