Build in Public
Should You Share Revenue When Building in Public?
Use a four-question disclosure test to decide when SaaS founders should share revenue and growth metrics publicly—and when to keep them private.
By Uriel Bitton · 4 min read
The short answer
SaaS founders do not need to share revenue to build in public. Share a metric only when it helps a relevant audience understand progress, learn from an experiment, or make a useful decision—and when the downside is acceptable. Add context, avoid customer or contract-sensitive data, and remember that public numbers are hard to retract. As the company grows, use ranges, delays, or lessons instead of raw metrics when risk rises.
SaaS founders do not need to publish MRR to build in public. Share a metric when it helps a relevant audience understand progress, learn from an experiment, or make a useful decision—and when you are comfortable with the number staying public. If exact revenue adds little beyond attention, share the lesson, range, or direction instead.
Revenue is optional; useful evidence is not
Building in public works through evidence, not mandatory disclosure. A product decision, failed experiment, onboarding change, or customer-safe observation can show real work without exposing financial detail. Buildside’s practical guide to building in public already recommends screening updates for customer, contractual, commercial, and operational risk before publishing.
Some companies choose much deeper transparency. Buffer’s current public metrics dashboard exposes revenue, customer, churn, usage, and marketing metrics. Buffer also documented the launch of its public revenue dashboard in 2020 as part of a broader transparency practice. That shows one valid model, not a rule every founder should copy.
Use a four-question disclosure test
1. What job will this number do?
Name the purpose before posting. A metric might explain why you changed pricing, show the result of a launch experiment, give context to a difficult decision, or help another founder compare a process. “People like revenue screenshots” is not a strong enough reason by itself.
2. Who benefits from knowing it?
A useful number should help a reader you actually care about: a customer, candidate, partner, investor, or founder facing the same decision. If the likely audience is mostly spectators while the downside falls on your company, publish the lesson instead of the raw figure.
3. What becomes harder once the number is public?
Public numbers can affect perception and leverage. Ask whether the figure reveals customer concentration, pricing power, pipeline weakness, cash pressure, a negotiable constraint, or another detail you would prefer not to hand to a counterparty. Also screen for customer confidentiality and contractual obligations.
GitLab’s transparency guidance explicitly documents exceptions for privacy, contractual obligations, legal concerns, and limited-access information. Its guidance is useful because it treats transparency as a practice with boundaries rather than a command to publish everything.
4. Will the context travel with the number?
A screenshot can outlive the post that explained it. If you share a metric, define it, give the time period, explain what changed, and separate what you observed from what you think caused it. “MRR grew 18% after launch” is weaker than explaining whether new customers, expansion, churn changes, or a one-time event drove the movement.
Choose the lowest-risk version that preserves the lesson
You often have more than two choices between exact disclosure and silence.
Share the exact number when the number itself is the useful evidence and the downside is acceptable.
Share a range when scale matters but precision does not.
Share a percentage change when direction matters more than the base.
Delay the metric when timing creates unnecessary commercial risk.
Share the decision and lesson without the metric when the number adds little value.
For example, a founder can explain that a pricing test increased paid conversion without publishing total revenue, customer names, or the exact economics of a major account. The public lesson remains useful while the private details stay private.
Change the boundary as the company changes
A disclosure policy that made sense at $0 MRR may not make sense after enterprise contracts, employees, investors, or regulatory obligations enter the picture. GitLab’s guidance on being a public company notes that the timing or detail of some key metrics can change and that certain revenue indicators are no longer exposed externally. Transparency can evolve without abandoning the principle behind it.
Review your boundary every few months. Buildside’s founder-brand framework is a useful reminder that the goal is a recognizable body of useful work around the problem you solve. Exact MRR is only one possible proof point.
Use this rule before your next metrics post
Before publishing a number, write four short answers: the job, the audience, the irreversible downside, and the context. If you cannot explain why the exact metric improves the post, remove it. If the lesson survives as a range, percentage, delayed number, or decision story, use the safer version.
Building in public should make the company more understandable, not more exposed than necessary. Share enough evidence to earn trust and create useful conversations. Keep the rest private on purpose.
Sources
Frequently asked questions
Do I need to share MRR to build in public?
No. You can build in public with product decisions, experiments, failures, customer-safe lessons, screenshots, and progress without publishing revenue. Share MRR only when the number serves a clear purpose and the commercial downside is acceptable.
What startup metrics are safer to share publicly?
Metrics are safer when they are aggregated, non-identifying, correctly defined, and unlikely to reveal sensitive customer, pricing, pipeline, or security information. A milestone, range, or delayed figure can sometimes preserve the lesson while reducing exposure.
When should a founder stop sharing exact revenue numbers?
There is no universal threshold. Reassess when exact numbers begin affecting negotiations, competitive exposure, customer perception, contractual obligations, investor communications, or legal requirements. The right boundary can change as the company grows.
How should I add context to a public SaaS metric?
State what the metric measures, the period it covers, what changed, and what you think caused the change. Separate observation from interpretation, and avoid implying that one short-term movement proves a durable trend.
A note from Uriel Bitton
Revenue screenshots are not a requirement for building in public. A number should earn its place by helping the right reader understand the business, the experiment, or the decision. If the same lesson can be shared with less exposure, I would usually choose the lower-risk version.
Keep building with us
Get practical founder lessons and product updates in your inbox.