Build in Public
How to Build in Public Without Oversharing Your Startup
Use a simple Lesson–Leverage Test to share useful startup progress without exposing customers, confidential terms, security details, or sensitive strategy.
By Uriel Bitton · 4 min read
The short answer
To build in public without oversharing, separate the useful lesson from the raw detail that creates risk. Share decisions, evidence, and learning, but remove or generalize customer-identifying information, confidential terms, credentials, unresolved security details, and strategically sensitive timing. When the lesson survives without the sensitive detail, publish the lesson and keep the leverage private.
Building in public does not require publishing everything you know. The safest approach is to separate the lesson that helps the reader from the raw detail that creates customer, contractual, security, or strategic risk. Use a Lesson–Leverage Test: identify what the audience should learn, then ask which details give away leverage without improving that lesson. Share the lesson. Remove, generalize, or delay the rest.
Transparency needs boundaries to stay useful
A highly transparent company can still keep important information private. GitLab describes itself as public by default, while its confidentiality guidance keeps items such as customer-identifying information, contracts, sales pipeline details, and some financial information internal or limited-access. That is a useful model for founders: transparency is a policy for useful information, not a promise that every fact becomes public.
Privacy is not the opposite of building in public. You can explain a customer problem, the decision it triggered, and what changed without publishing the customer’s identity, contract, exact terms, or private conversation.
Use the Lesson–Leverage Test before every update
Start with the complete story in a private note, then ask two questions.
1. What is the lesson?
Name the smallest useful thing the reader should understand: why you rejected a feature, what surprised you during onboarding, how an experiment changed positioning, or which tradeoff shaped a decision.
2. What leverage is hidden inside the raw detail?
Look for information whose disclosure creates risk without making the lesson materially better:
Customer leverage: names, screenshots, private messages, small cohorts, or details that make a customer identifiable.
Contractual leverage: NDA-covered information, negotiated terms, partner restrictions, or unpublished deal details.
Operational leverage: credentials, tokens, internal identifiers, active vulnerabilities, security controls, or reproducible failure paths.
Commercial leverage: live pipeline information, negotiating positions, sensitive pricing tests, unit economics, or exact information a counterparty can use against you.
Strategic leverage: exact timing, implementation details, or sequencing that matters more to your advantage than it does to the reader.
If the audience can learn the same lesson after one of those details is removed, the detail is not part of the public story.
Removing a customer name may not anonymize the story
Be careful with customer stories, especially when your startup has only a few users or enterprise accounts. The UK Information Commissioner's Office explains that identifiability is broader than a person's name: information can become identifying when it is combined with other available details. Its anonymisation guidance specifically tells organizations to consider singling out, linkability, and the context in which information is released.
Instead of writing, “Our only Montreal fintech customer with 40 employees asked for this,” you may be able to say, “A customer in a regulated industry exposed a workflow problem we had underestimated.” The second version preserves the lesson while reducing identifying context. When the customer story itself matters, get permission.
Security lessons should not become security instructions
Technical transparency needs an even harder boundary. GitHub's secret-leakage guidance notes that credentials can leak through repositories, configuration files, documentation, issues, discussions, and logs, and that exposed secrets can provide unauthorized access to systems and data.
If you hit a security incident, share the lesson after the dangerous detail is removed or the issue is remediated. “We moved credentials out of local configuration and added automated scanning” can be useful. A live token, exact unresolved exploit path, production identifier, or current control weakness is not proof of authenticity.
Share the decision, not necessarily the entire roadmap
A public roadmap can help users understand direction, but you do not need to publish every feature, deadline, technical approach, and dependency. Often the useful public version is the problem you are prioritizing, why it matters, what you are testing, and what evidence will determine the next decision.
This extends Buildside's practical guide to building in public, which recommends screening updates for customer, contractual, commercial, and operational risk. For numerical disclosures, Buildside's SAFE test for SaaS metrics goes deeper on when to share, generalize, delay, or keep a number private.
Use a 15-second pre-publish check
Before publishing, read the post once as four different people: the customer mentioned, a competitor, an attacker, and someone negotiating with your company. Then ask: what can each person infer that the intended reader does not need?
If the useful lesson survives without a name, exact number, implementation detail, or exact timing, remove that detail. If the post becomes meaningless after removing it, wait until the information is safe to share or choose a different lesson.
Building in public works best when transparency earns trust instead of spending it. Show enough of the work to make your reasoning useful and credible. Keep the parts that protect customers, security, contracts, and real business leverage private.
Sources
Frequently asked questions
What should founders keep private when building in public?
Keep customer-identifying information, confidential contract terms, credentials, unresolved security details, private conversations, and strategically sensitive information private when disclosure creates more risk than value. You can usually share the lesson without sharing the raw detail.
Can I share customer feedback without naming the customer?
Sometimes, but removing a name may not be enough if the company or person can be inferred from industry, size, location, timing, or other details. Get permission when appropriate or generalize the story until the customer is not reasonably identifiable.
Should I share my public roadmap when building in public?
Share the problem, direction, or experiment when that helps users understand the product, but you do not need to publish every feature, implementation detail, deadline, or strategic sequence. The useful public unit is often the reasoning, not the complete internal roadmap.
How do I know if a build-in-public post overshares?
Ask whether a reader could learn the same useful lesson if you removed the identifying name, exact number, exact implementation, or exact timing. If yes, remove or generalize that detail before publishing.
A note from Uriel Bitton
Useful transparency is selective. I want Buildside founders to share enough evidence that readers can understand the work and learn from it, while keeping customer trust, security, contractual obligations, and genuine business leverage intact.
Keep building with us
Get practical founder lessons and product updates in your inbox.