Share with boundaries

Public does not mean exposed

A boundary is not an obstacle to Build in Public. It is the rule that makes the practice sustainable.

Share what you created, observed, and learned. Be careful with information that belongs to another person, weakens security, or cannot be recalled once copied.

Never publish these by accident

• API keys, access tokens, private URLs, session cookies, or recovery codes;
• customer names, email addresses, payment details, support conversations, or analytics identifiers;
• internal contracts, unreleased partner information, or employer-owned work;
• security vulnerabilities before responsible disclosure and remediation;
• a collaborator's draft, message, image, or opinion without consent;
• location and routine information that creates a personal safety risk.

Screenshots deserve the same review as source code. Browser tabs, terminal history, environment files, notifications, and image metadata can reveal more than the subject of the screenshot.

Separate the lesson from the secret

You can often publish the useful idea after removing identifying details.

Instead of sharing a customer's message, write:

Three early users expected export to preserve the visible sort order. I had treated export as raw data, but they treated it as a report. I am testing both options now.

The lesson survives. The private conversation does not need to become content.

Revenue is optional

Revenue transparency can help explain pricing, sustainability, or a business experiment. It can also attract unhelpful comparison, expose negotiating positions, or make every update feel like a scoreboard.

Share revenue only when the number teaches something and you accept the consequences of making it durable. You can discuss direction, conversion, costs, or a pricing lesson without publishing exact income.

Protect unfinished thinking

Not every draft benefits from immediate reaction. Some decisions need private exploration, especially when the audience lacks the context to distinguish a question from a commitment.

Use a delay when needed:

• write privately during the experiment;
• make the decision;
• publish a retrospective explaining the alternatives and evidence.

This is still building in public. The public receives an honest record, not a live broadcast.

Protect your attention

Set a publishing budget. For example, spend ten minutes capturing notes during the day and twenty minutes editing one weekly update. Do not let the post consume the session it is meant to document.

Turn off metrics when they change your behavior in ways you dislike. A quiet, useful archive can be more valuable than a high-performing post that pulls the project in the wrong direction.

The pre-publish review

Ask these questions every time:

1. Is this my information to share?
2. Does the reader need this level of detail to learn the lesson?
3. Can this harm a user, collaborator, employer, or the project?
4. Does the screenshot contain hidden context?
5. Would a delayed retrospective be safer or clearer?
6. Am I prepared for this to remain searchable?

Boundary checklist

• [ ] Secrets and private identifiers are removed.
• [ ] People appearing in the story have appropriate consent.
• [ ] The post does not violate an agreement or disclosure process.
• [ ] I kept personal details that do not serve the lesson private.
• [ ] Publishing will not consume the time needed to do the work.
• [ ] I can explain why this information is useful to share.

Good boundaries make it possible to continue for years instead of oversharing for a month and disappearing.