What is Build in Public?

The short definition

Build in Public is the practice of sharing useful parts of your work while the work is still happening.

The work can be a product, an open-source project, a book, a design practice, a research question, or a skill you are learning. You show evidence of progress, explain decisions, ask focused questions, and record what changed.

The word public describes who can see the work. It does not mean that every part of your life or business must be exposed.

The basic loop

Most useful Build in Public journeys follow a simple loop:

1. Make something. Create a small artifact: a sketch, commit, prototype, paragraph, test, or customer note.
2. Show the evidence. Share what exists now instead of only describing a future plan.
3. Add context. Explain what you tried, where you got stuck, or why you chose one direction.
4. Invite a useful response. Ask one question that another person can realistically answer.
5. Use what you learn. Keep, reject, or test the feedback, then record the decision.

Building remains the source. Publishing helps you inspect the work, meet people who care about it, and preserve what you learned.

What it is not

Build in Public is not a requirement to post every day. It is not a promise that an audience will appear. It is not a substitute for talking directly with users. It is not permission to reveal customer data, private conversations, credentials, contracts, or a collaborator's work.

It is also not limited to founders. A developer can explain an architectural tradeoff. A student can publish weekly learning notes. A designer can show how a draft changed. A writer can share an outline and the question behind it.

Public work has two homes

Fast updates belong in feeds such as X, LinkedIn, Reddit, or a community forum. Durable knowledge belongs somewhere you control: a README, changelog, project website, newsletter archive, or personal site.

The feed helps people discover the work. The durable home helps them understand it six months later.

Start with one of each only when you need both. A GitHub README by itself is already enough to begin.

A first example

An empty announcement says:

I am building a new productivity app. Big things coming soon.

A useful public note says:

I am testing a timer that ends a work session by asking what actually changed. Today I built the first browser prototype. The hard part is making the final question useful without becoming annoying. If you use a focus timer, what do you want to remember when a session ends?

The second note contains an artifact, a decision, a difficulty, and a focused question. A reader knows what is real and how to respond.

Your first action

Do not design a content strategy yet. Write four lines in a private scratchpad:

I am working on:
Today I changed:
The difficult part was:
Next I will:

Publish it only after removing anything private. Add a screenshot or link if one genuinely helps.

Before you continue

• [ ] I can name the thing I am working on.
• [ ] I know which part can be public.
• [ ] I have one durable place where the work can live.
• [ ] I understand that attention is optional; learning is the return.

Next step: decide whether this practice fits your work, personality, and constraints.