What Not to Share Build in Public: The 12 Categories to Keep Private

TL;DR

• Build in public is selective transparency, not radical transparency. 12 specific categories should stay private even when the rest of the practice is public.
• The biggest mistakes: sharing customer data without permission, exposing security vulnerabilities, posting legal matters in progress, sharing employee compensation discussions publicly.
• The honest framing: maximum transparency on your own work and learnings; default-to-private on anything that belongs to or affects others.

The 2019 culture of build-in-public pushed toward maximum transparency. The 2026 culture has matured into selective transparency — sharing your work and learnings while protecting things that should remain private. This cluster sits inside our build in public pillar and pairs with what to share build in public on the positive list.

The 12 categories to keep private

1. Specific customer data

Customer names, company affiliations, usage patterns identifiable to specific users — all private without explicit written permission. The B2B norm is more restrictive than B2C; many enterprise customers have explicit policies against vendor reference posts.

The exception: with explicit written permission, customer-story content is high-leverage. The discipline is permission first, content second.

2. Employee / contractor compensation

Salaries, equity grants, contractor rates — all private. Sharing one person's compensation publicly creates anchoring effects on future hires and exposes individuals to comparison. Even aggregate compensation should be careful (industry-aggregate ranges OK; specific company averages less so).

3. Hiring conflicts and team disputes

Disagreements with team members, performance issues, hiring rejections — all private. The professional norm is to handle these in private; public-by-default makes future team formation harder.

4. Legal matters in progress

Active disputes, IP issues, regulatory inquiries — all private until resolved (and often after). Sharing legal matters in progress can affect outcomes, expose you to liability, and damage relationships with the other parties.

5. Security vulnerabilities pre-patch

Security issues should be private until patched + tested. Public disclosure before patch is irresponsible — even when the disclosure is "I found this and fixed it," the timing matters. After-patch disclosure is OK; pre-patch is not.

6. Acquisition discussions

Any discussions about acquiring or being acquired stay private until closed. Public discussion typically tanks deal terms or kills the deal. Even confirming "we are talking to acquirers" creates downstream problems.

7. Financial details past Belogubov's thresholds

Specific MRR / ARR / margin / runway numbers past the ~$10K MRR threshold (per when to go ghost mode founder). Aggregate framing OK; specifics not.

8. Investor communications

What you tell investors privately stays private. The "we are crushing it" message to investors and the "honest reflection" public post should not contradict each other, but they also do not have to be identical.

9. Specific personal information

Family details, home address, daily schedule, partner / children information — all private. The "share everything about your founder journey" framing does not extend to your personal life.

10. Competitive intelligence about specific companies

Specifically: do not publicly call out competitors by name except in explicit-comparison contexts where you can be factually accurate. Anonymized competitive analysis is fine; named attacks are not.

11. Code that contains secrets / credentials

Even when sharing .cursorrules or code snippets publicly, scrub anything that contains API keys, customer-specific patterns, or proprietary business logic. The discipline is publish the patterns, hide the specifics.

12. Internal strategic decisions until shipped

Strategy decisions (pivoting, repositioning, sunsetting a feature) should stay internal until they ship. Public discussion of in-progress strategic decisions creates expectations that may not match what actually ships.

The "default to private when in doubt" principle

The discipline that solves most edge cases: when uncertain whether to share something, default to private. The marginal cost of not sharing is rarely significant (you can share later if needed); the marginal cost of sharing something that should have been private can be permanent.

Examples of edge cases:

• A customer just emailed you something interesting — default to anonymizing or asking permission
• A team member did something noteworthy — default to celebrating internally first, public only with permission
• You learned something proprietary in a partnership conversation — default to private until the partnership is structured publicly

What this list does not mean

Selective transparency is not opacity. The 12 categories above are bounded. Outside them, the maximum transparency framing still applies:

• Your work, your decisions, your learnings — all shareable
• Your honest opinions on industry trends — all shareable
• Your aggregate metrics (under the thresholds) — shareable
• Your cost transparency — shareable
• Your failures and mistakes (your own, not others') — shareable

The category list is the negative space; everything outside it remains the default-share territory.

The honest cost of over-sharing

Specific harms that show up when these categories get violated:

• Customer trust collapse. A single public post about a specific customer without permission can lose that customer + 5-10 referrals.
• Legal exposure. Sharing matters under NDA or in active litigation can produce real legal consequences.
• Brand damage. Public competitor attacks usually backfire; the audience views it as low-status.
• Personal safety risk. Detailed personal information shared publicly can be used against you.

These costs are usually invisible until they materialize, at which point they are often permanent.

Sibling clusters

• Build in public — the head-term pillar
• What to share build in public — the positive list
• Build in public revenue sharing — the MRR specifics
• When to go ghost mode founder — late-stage transitions
• Build in public for B2B SaaS — where the restrictions are tighter

FAQ

Can I share customer stories at all? Yes, with explicit written permission. Customer-story content is high-leverage when done right; the discipline is permission first, content second. Anonymized customer stories ("a 50-person consulting firm in the Bay Area") work without permission.

What about sharing my own salary / income? Your personal income is your call. Sharing produces transparency benefits + creates comparison-attention costs. Many founders share at low income levels and stop sharing past Belogubov's thresholds. The decision is yours but not casually — once shared, the number is anchored.

Should I share my hiring process publicly? Generally only at aggregate level. Specific candidate conversations, rejections, salary negotiations stay private. The hiring process patterns (how you structure interviews, what you look for) are shareable; specific candidates are not.

Can I publicly call out a competitor for misleading marketing? Be very careful. Specific factual claims with sources are OK in some cases; broader attacks usually backfire. Default to anonymized framing ("some tools in this space overclaim X; we do not"). Named attacks invite retaliation and create permanent association.

What if a customer publicly criticizes me — can I respond with their data? No. Even if they shared first, you respond with the public information they shared, not with internal data they did not consent to making public. Customer relationships require asymmetric privacy obligations — you protect their data even when they do not protect yours.

Building is no longer the bottleneck. Visibility is. buildinpublic.so is narrative infrastructure that runs inside your building workflow — with selective transparency built in: Loudy drafts content from your AI Brain memory that excludes the 12 private categories by default, Dev Cards classifies commits and skips ones touching sensitive areas, and the human-approval gate catches anything that slips through.