Build in Public
Which SaaS Metrics Are Safe to Share Publicly? Use This 4-Gate Test
Decide whether to share SaaS metrics exactly, generalize them, delay them, or keep them private using a four-gate customer, contract, strategy, and…
By Uriel Bitton · 4 min read
The short answer
No SaaS metric is automatically safe to publish. Before sharing MRR, churn, customer counts, conversion rates, or other numbers, check whether the metric could identify a customer, breach an agreement, weaken useful commercial leverage, or reveal sensitive operational information. Then share it exactly, generalize it, delay it, or keep it private.
Which SaaS metrics are safe to share publicly depends less on the metric’s name than on what someone can learn from it. MRR, customer count, conversion rate, churn, and growth can all be reasonable to share in one company and risky in another. Before publishing a number, test whether it can identify customers, violate an agreement, weaken useful commercial leverage, or expose sensitive operational information.
Use the SAFE test before publishing a metric
Run every metric through four gates.
S — Can the number single someone out?
Removing customer names is not always enough.
Imagine a SaaS has three enterprise customers and publicly says one customer represents 62% of MRR. If people already know who those customers are, the number may reveal information about an identifiable company relationship. User-level metrics create an even clearer privacy concern when an individual can be identified.
The UK Information Commissioner’s Office warns that apparently anonymous information can remain identifiable through singling out or linkability with other available information. Its guidance recommends greater care when information is released publicly rather than to a controlled group.
If a metric fails this gate, broaden the cohort, remove dimensions, use a range, or do not publish it.
A — Are you allowed to disclose it?
Check the source of the number.
Customer contracts, NDAs, partner agreements, acquisition discussions, investor communications, and private customer conversations can create restrictions that have nothing to do with whether the metric looks anonymous.
“Enterprise retention improved this quarter” may be harmless. “Our only healthcare customer renewed at $42,000 ARR” could disclose considerably more.
When you are uncertain about a contractual or legal obligation, keep the number private until the obligation is checked.
F — Does the exact number cost you useful leverage?
Privacy is not the only reason to generalize a metric.
Exact MRR, CAC, margins, churn, pipeline value, or customer concentration can affect how a potential customer, competitor, investor, employee, or acquirer evaluates the business. That does not make these metrics inherently secret. It means the founder should decide whether the exact number adds more value to the public update than it removes elsewhere.
share the percentage change instead of the absolute number
publish a range
describe the experiment and result without the underlying commercial figure
delay the update until a negotiation or launch is finished
The useful question is not “Am I transparent enough?” It is “Does this precision help the reader understand the lesson?”
E — Does the metric reveal operational exposure?
Be cautious when a metric becomes a map of the system behind it.
Broad uptime, latency improvements, infrastructure-cost reductions, or incident lessons can be useful. Exact capacity thresholds, unresolved failure conditions, internal identifiers, credentials, customer-specific infrastructure, or security-sensitive architecture should not be included merely to make an update feel more authentic.
Share the engineering lesson without publishing what someone would need to reproduce the weakness.
Lower-risk metrics still need context
Company-level metrics are often easier to share safely when they are aggregated across enough activity. Examples include:
broad MRR or ARR milestones
total paying customers
monthly or quarterly growth
aggregate activation or conversion rates
broad churn trends
waitlist or signup totals
uptime or performance improvements
product-shipping milestones
None is automatically safe. A conversion rate based on four identifiable enterprise prospects is different from the same metric across thousands of anonymous sessions.
That distinction follows the same principle described in GDPR Recital 26: identifiability depends on information that can reasonably be combined to identify a person, not simply whether a name was removed.
Use four disclosure levels instead of public versus private
For each metric, choose one outcome:
Share exactly when all four SAFE gates are comfortably clear.
Generalize when the lesson matters but precision does not. Use a range, percentage, rounded number, or larger cohort.
Delay when the information is safe eventually but sensitive during a negotiation, experiment, incident, or launch.
Keep private when disclosure creates customer, contractual, security, or meaningful business risk.
Buildside’s guide to what SaaS founders should share covers the rest of a useful build-in-public update: the problem, decision, experiment, evidence, tradeoff, lesson, and next step. A metric should support that story, not force the founder into unnecessary disclosure.
Before your next metrics post, write the number down privately and run it through Singling out, Agreements, Future leverage, and Exposure. If the exact figure fails one gate, change the disclosure—not the lesson.
Frequently asked questions
Is it safe for a SaaS founder to share MRR publicly?
It can be, but MRR is not automatically safe. Consider customer identifiability, confidentiality obligations, current negotiations, and whether publishing the exact number creates a commercial downside; a milestone, range, or growth rate may communicate the lesson with less exposure.
Can I share customer metrics if I remove customer names?
Not necessarily. Small cohorts, industries, locations, dates, public customer lists, and other details may allow someone to infer who the metric describes. Assess whether people can be singled out or the data linked with other available information.
What should I do if a SaaS metric feels too sensitive to publish?
Reduce the precision rather than abandoning the useful lesson. Share a percentage, range, rounded figure, larger cohort, delayed result, or the decision and outcome without the underlying number.
A note from Uriel Bitton
Useful transparency is deliberate, not maximal. The goal is to give other founders enough evidence to understand the decision and lesson without exposing customers or creating unnecessary risk for the business.
Keep building with us
Get practical founder lessons and product updates in your inbox.