How to build in public: what to share, where and how often

What does it mean to build in public?

Building in public means you make a product while other people watch. You post what you worked on, what went wrong, what users said and, if you choose, the numbers. The audience may be a few followers, a newsletter list, a forum thread or the whole public internet. The opposite is stealth mode, where nothing is shown until launch day.

The practice is not new. Buffer, the social media scheduling company, describes defaulting to transparency as its “North Star” value and notes that transparency is the thing it is best known for. Plausible Analytics goes further and publishes the traffic of its own website on a public dashboard. Indie Hackers, a community for independent founders, was built around founders telling how they earn money from their products; TechCrunch reported in 2017 that the site had published dozens of interviews with independent founders.

Building in public is a spectrum, not a switch. You decide how much to show, and you can change your mind. The table lists the usual levels from least to most open.

Most solo builders do well at levels 1 to 3. Levels 4 and 5 suit people who like the discipline of being measured in public and who have the kind of product where openness is part of the pitch.

Why build in public?

There are four honest reasons, and none of them promises a crowd.

• Accountability. A weekly post is a small deadline. If you told people you would ship the sign-up page this week, you are more likely to ship it.
• Faster feedback. Showing a half-finished screen gets you reactions before you have spent a month building the wrong thing.
• A trail of trust. By launch day, people who followed along have seen you work. That counts for more than a polished landing page from a stranger.
• A written record. Your posts become a build log you can reread, reuse as launch copy, or turn into an article.

It does not fix a weak idea, and it does not create an audience by itself. If nobody follows you, your first posts reach nobody. That is fine, because the habit still helps you. For the audience problem, see the guide to launching without an audience, which covers where to find first users.

What should you share when you build in public?

Good updates are specific and short. “Working on the app” says nothing. “Fixed the bug where the reminder email went out twice, and added a test so it cannot come back” is a post a reader can picture. Use this table to pick.

Post numbers only if they come straight from your own dashboards, and say what the number is. Never round up, never imply you earn more than you do. A small honest figure is more useful to readers than a large vague one.

Where should you build in public?

Pick one home base and one or two places to share links. A home base is somewhere you own and can point to later; a place to share is where people already gather. Spreading yourself across five platforms usually means you post nowhere.

• Your own site or changelog. A simple page with dated entries is a build log you control. It stays after a social platform changes.
• A social account. Pick the one platform where the people you want to reach already spend time, and read its rules on self-promotion.
• Communities for makers. Forums such as Indie Hackers are built for founders sharing progress. Read each community’s posting rules first, since many limit self-promotion.
• A newsletter. If you collect emails, send a short monthly summary. Subscribers are the people most likely to try the launch.

Whatever you choose, link back to one place where people can try the product or join a list. Updates with no next step are applause, not progress.

How do you build in public without it eating your time?

Treat it as a fifteen-minute habit tied to work you already do. The trick is capturing material while you build, not trying to remember it on Friday.

1. Keep a build log. One text file, one line per day: what you did, what surprised you. This is your raw material.
2. Pick a fixed time. Choose one regular slot, for example Friday afternoon, and write one post from the log.
3. Add one visual. A screenshot, a short screen recording or a chart makes a post easier to read than a paragraph.
4. End with a question or next step. “Next week: sign-up emails. What would you want in the first one?”
5. Reply to comments the same day. Replies are where the relationships form.

If you build with an AI coding agent, let it draft the log for you. This prompt works in Claude Code, Cursor or any tool that can read your git history. Check the draft against what really happened before you post it, since the agent only knows what is in the commits.

Run `git log --since="7 days ago" --pretty=format:"%h %s"` and read the output.
Write a build-in-public update of at most 120 words in plain English for people who do not code.
Structure: one line on what shipped, one line on what broke or surprised me, one line on what I will do next week.
Use only what is in the commit messages. If something is unclear, list it as a question for me instead of guessing. No hashtags, no emojis, no claims about users or revenue.

Week [number] of building [product name].

Shipped: [one concrete thing]
Broke or surprised me: [one honest line]
Number: [one figure from your own dashboard, with what it measures]
Next week: [one thing]

Question for you: [one question that someone can answer in a sentence]

Try it: [link]

How does build in public lead into a launch?

A launch is the one update with a big call to action. If your past updates show what you built and why, your launch post can lean on them: a line of the story, a link to the best clip, and the page where people can try the product. The free launch copy generator can help you draft a tagline, and the free launch directories tool compares places to post it.

Before launch, decide what you will tell people about price. If you have shown revenue numbers, the same honesty applies to a launch: do not invent testimonials or quotes. The Federal Trade Commission publishes a rule on consumer reviews and testimonials that prohibits fake or false ones. Use only words real users gave you, with permission.

Can building in public go wrong?

Yes, in a few predictable ways.

• Performing instead of building. If you spend more time on posts than on the product, cut back. The product is the point.
• Pressure from numbers. Publishing a sign-up count every week can push you toward vanity goals. Share the numbers that match your real aim, such as repeat use.
• Copycats. Someone may copy a visible product. Ideas are cheap and execution is hard to copy. The guide to protecting an app idea explains what protection exists and what does not. If a particular detail truly matters, keep it back until launch.
• Sharing others’ information. Users, clients and collaborators did not agree to be content. Ask first.
• Painting yourself into a corner. Public promises are hard to retract. Say “I am planning” rather than “I will definitely”.

If you are not sure a project is worth finishing, you can still share it in the smallest way: write the idea down and post it on the board. It takes a minute, and another builder may take it further. The ideas already on the board also show how short a useful description can be.