Build in Public in the AI Era: What to Share and What to Keep Private

Building in public does not require choosing between silence and publishing an operating manual for your competitors. The useful question is narrower: for each thing you could share, will the feedback, trust, or connection it creates be worth the risk of making it public?

AI has shortened the path from seeing a feature to producing a rough imitation of it. That changes the disclosure calculation, but it does not reduce the cost of copying a durable business to zero. Distribution, customer relationships, operational knowledge, proprietary data, and years of accumulated decisions are harder to reproduce than a visible interface.

The answer is not to abandon build in public. It is to replace indiscriminate transparency with strategic transparency: share what helps people understand your judgment and progress, while protecting information that creates avoidable risk.

Decide What to Share One Artifact at a Time

Before publishing a screenshot, technical note, metric, prompt, or launch plan, ask five questions:

1. Is it mine to disclose? Customer, employee, partner, and investor information may not be yours to make public.
2. Could it create a privacy or security risk? Credentials, internal endpoints, authentication flows, live vulnerabilities, and identifiable user data should not become content.
3. Does it reveal a repeatable advantage before that advantage has had time to compound? A lesson can be valuable without including every threshold, query, prompt, or decision rule behind it.
4. Can the disclosure be reversed? A post can be deleted, but screenshots, copied data, and indexed details may remain elsewhere.
5. What will sharing produce? If it can attract useful feedback, document a real lesson, or deepen trust, the value may outweigh the copying risk. If it only fills the content calendar, it probably does not.

This turns build in public into a series of deliberate decisions rather than a rule that everything must be shared.

Share the Judgment, Not Every Instruction

The most useful public work usually explains how a decision was made:

• Reasoning and tradeoffs: Explain why you chose one direction, which constraints mattered, and what you gave up. A competitor can see the decision, but your audience learns how you think.
• Lessons from failure: Share the diagnosis and what changed after the problem was resolved. There is little public value in exposing an active vulnerability or giving outsiders a map of a fragile system.
• Domain-specific problems: Describe the difficult cases that generic demos ignore. You can show the depth of the problem without publishing customer data or the exact implementation.
• Outcomes with enough context: Directional results, assumptions, and limits are often more useful than isolated revenue or conversion screenshots.
• The evolution of the product: Changes in your understanding of the customer are harder to copy than a feature list and usually more valuable to readers.

AI can help someone reproduce visible features more quickly. It does not automatically give them the same sequence of customer conversations, operational constraints, and decisions that shaped the product. Those assets are not impossible to copy, but they are usually slower and more expensive to rebuild.

Keep Sensitive and Premature Details Private

Some information should stay private regardless of how useful it might look as content:

• Customer data, private conversations, contracts, and confidential partner information
• Credentials, security weaknesses, internal administration routes, and detailed authentication architecture
• Unreleased plans whose value depends heavily on timing
• Exact operating recipes that currently provide a repeatable advantage
• Metrics that expose another party or create a misleading comparison without context

Timing also matters. You may share a campaign, SEO experiment, or launch tactic after it has run and produced a lesson. Waiting can reduce unnecessary risk, but it does not guarantee a permanent first-mover advantage. The point of delayed transparency is to publish from evidence instead of exposing an untested plan.

What Technical Controls Can and Cannot Do

Content strategy cannot protect a resource that is publicly accessible. If information must remain private, keep it behind real controls such as authentication, authorization, rate limits, server-side boundaries, and appropriate secret management. Do not ship sensitive data to the browser and expect a policy statement to protect it.

robots.txt communicates crawl preferences to bots that honor it; it is not access control. The Robots Exclusion Protocol makes clear that listed paths remain public and discoverable. Some providers offer controls for their own crawlers, as Anthropic does for ClaudeBot. Those rules do not bind every scraper or prevent a person from opening a public page.

An AI usage policy or license states what you permit; it is not technical protection. There is no documented HTML behavior that makes custom ai-usage-policy link tags or ai-usage-restrictions meta tags cause models to refuse cloning requests. The HTML Standard does not define that behavior.

The boundary is straightforward: use policy to communicate terms, crawler directives to express preferences, and access controls to protect nonpublic systems and data.

Build Trust Without Publishing the Blueprint

Build in public remains useful because it can create feedback, accountability, trust, and a community around the work. AI does not remove those benefits. It raises the cost of sharing carelessly.

Share the problem, the tradeoffs, the wrong turns, and what you learned. Protect other people's information, active security details, and the small number of operating choices that genuinely create an advantage. The goal is not maximum visibility or maximum secrecy. It is publishing enough to be useful without giving away information you were responsible for protecting.