Build in Public.

A public build update might show an unfinished screen, explain a tradeoff, report an experiment, or describe a mistake. The useful part is the context: who the work serves, what you are trying to accomplish, and what you know so far. A reader should be able to understand the update without following every post you have written.

You can build in public before you launch and continue after you have customers. Early updates may focus on a problem or prototype. Later updates might explain how you improve onboarding, decide what to prioritize, or respond to support questions. The practice can create a record of your reasoning as well as a way for other people to discover the product.

It does not require broadcasting every work session. You choose the details, the pace, and the audience. Sharing a clear decision with relevant people can be more useful than publishing a daily activity log that nobody knows how to respond to. A public update also does not replace speaking privately with customers or observing someone use the product.

These approaches can overlap, but choosing one does not commit you to all of them. A closed-source product can have a public development story. A public launch can be the first time anyone hears about a privately built product. Read more about building in public versus open source.

Building in public is a good fit when showing the work can help someone understand a problem, contribute a perspective, or decide whether to try the product. It can help you find peers, make your thinking easier to explain, and keep a visible record of progress. Those are useful possibilities, not automatic outcomes of posting.

The most common mismatch is confusing a supportive founder audience with a customer audience. Other builders may enjoy your progress and offer excellent advice while having no reason to buy the product. That does not make the community useless. It means you should judge peer support and customer demand separately.

There is also a cost to keeping a public story going. Replies, editing, and checking numbers take time. Start with a small commitment, review it after a few weeks, and change the routine if it is not helping. You are allowed to share less during a demanding release, protect unfinished ideas, or move a sensitive conversation into a more appropriate setting.

1. 01

   Choose one useful outcome

   Decide what you want this period of sharing to help you do. You might want to understand a customer workflow, find people willing to try a prototype, explain a difficult product tradeoff, or meet other founders working through the same problem. Pick one primary outcome so you can judge whether the activity is helping. A goal such as ‘learn where first-time users get stuck’ gives you a much clearer next post than ‘grow my audience’.

   Write: ‘This month, sharing my work should help me…’

2. 02

   Name the person you want to reach

   Be specific about whose experience would be useful. ‘Small businesses’ covers too many different situations. ‘Independent photographers who send client galleries every week’ tells you what to show, which words to use, and where to look for a response. Fellow founders can help with product decisions, but they are not automatically representative customers. Keep those two audiences distinct when interpreting their advice.

   Write down a role, a recurring task, and the problem that interrupts it.

3. 03

   Set your sharing boundaries

   Choose what you can comfortably publish before a busy day makes the decision for you. You can share a prototype with sample data, the reasoning behind a design choice, or a lesson without exposing private conversations. Decide whether revenue is in scope, which customer details must stay private, and whether an employer or collaborator needs to review material. A clear boundary makes consistency easier because every update does not become a fresh debate about disclosure.

   Make a short public / permission needed / private list.

4. 04

   Choose one main place to share

   Start where the people you want to learn from already have relevant conversations. Read several discussions before posting. Notice whether specific questions get thoughtful answers, whether links are welcomed, and how people introduce unfinished work. You do not need to launch a newsletter, record videos, and post across five networks in your first week. One place to talk and one durable record of your work are enough to begin.

   Pick a primary conversation space and decide where your updates will live.

5. 05

   Show a small, understandable piece of work

   Choose one artifact: a screen, a short demo, a sketch, an experiment result, or a before-and-after comparison. Explain who it is for and what changed. Avoid making readers reconstruct your whole startup before they can understand the question. If a feature is only a prototype, say so. If a measurement came from a local test, name the conditions. A narrow, honest example gives people something concrete to inspect.

   Finish the sentence: ‘Here is the part I can show today.’

6. 06

   Ask a question people can answer

   ‘Thoughts?’ asks the reader to invent the assignment. Try a question tied to a task instead: ‘What would you need to know before uploading your first client file?’ or ‘Where would you expect to find the export?’ Invite people to explain a recent experience. You will usually learn more from the context behind an answer than from a vote for your preferred option. Keep the question small enough that someone can respond without a meeting.

   Ask about one decision, one task, or one point of confusion.

7. 07

   Return with the decision

   After reading the replies or observing a test, explain what you did next. Credit useful contributions when appropriate, distinguish suggestions from evidence, and say what you still need to investigate. You do not have to implement every request. A thoughtful follow-up can explain why you kept the current approach. This closes the loop for people who gave their time and leaves a useful record for the next person who encounters the same question.

   Share: what you heard, what you changed, and what you will check next.

For a more specific starting point, use the guides for solo founders, B2B SaaS founders, or side-project builders. The audience changes the examples and the pace; the need for clear context remains.

A worked example: from a post to a product decision

The following sequence is fictional. It shows how to make the reasoning inspectable without inventing customer results. Framepath is an imaginary client-gallery product for photographers.

The same pattern works when the feedback is quiet or contradictory. Report that the post did not produce the perspective you needed, explain how you will find it, and avoid interpreting silence as rejection of the entire idea. A useful record includes unresolved questions.

Good material often comes from work you are already doing: a support question that reveals unclear wording, a prototype that makes an idea testable, a tradeoff between two workflows, or an experiment that changed your plan. Keep a small note during the week so you are not trying to invent a story when it is time to post.

When sharing a metric, include its definition and timeframe. “Twenty people registered between these dates” is different from “twenty active customers.” When sharing performance, state the test conditions. When sharing feedback, distinguish an individual’s preference from evidence of a broader need. These details make the update useful even when the numbers are modest.

For screenshots, check browser tabs, notifications, names, email addresses, and background panels before publishing. A realistic demo can use sample records. If redaction makes the image hard to understand, recreate the task with fictional data and label it as a demonstration. Explain the product behavior in text so someone can follow it without the image.

Go deeper with reporting feedback polls responsibly and sharing SaaS speed tests with context.

These templates are prompts, not scripts you need to follow forever. Keep the language you would use with a thoughtful peer. If you cannot fill a line honestly, leave it out or describe the uncertainty. The completed examples below use the fictional Framepath project; they are illustrations, not reports from real customers.

I’m building [product] for [specific people] who struggle with [task].
Right now I’m at [stage].
Here is [a sketch, demo, or observation].
The question I’m exploring is [one uncertainty].
If you do this task, how do you handle it today?

This week I changed [specific thing].
Before: [what happened].
Now: [what is different].
I made this change because [reason].
Still unfinished: [limit].
Next I’m checking [question or task].

Hypothesis: [what I expected].
Test: [what I changed and how I checked it].
Context: [dates, participants, environment].
Observed: [what actually happened].
Limits: [what this cannot tell us].
Next: [follow-up test or decision].

I’d value a perspective from [relevant person].
Task: [what a user is trying to do].
Current approach: [brief description or artifact].
Question: [one thing to evaluate].
Trying it involves [time, access, prerequisites].
Please avoid sharing [private information].

I expected [assumption].
Instead, [what happened].
This affected [specific task or plan].
What I know: [evidence].
What I don’t know yet: [uncertainty].
I’m changing [next step].

Milestone: [number or completed outcome].
Period: [start and end dates].
Definition: [exactly what is counted].
What contributed: [known activities].
What I cannot attribute: [limits].
Next priority: [how this changes the work].

A channel should make it possible to explain the work, get a relevant response, and return with an update. You may use a public network for discovery, a focused community for discussion, and your own site for a lasting record. Start with a combination you can maintain. The table is a practical selection framework, not a ranking of platforms or a promise of reach.

Buildside provides a founder feed, founder discovery, and product pages. Those can give your updates context and help people explore the work behind a question. They do not guarantee that your customer is present or that every post will receive feedback. Use the same audience-fit test here that you would use anywhere else.

Keep a copy of important updates, source images, and decisions. Before relying on any service as your only record, check how you can retrieve your content and what happens to links if you move. Read the content-portability guide and the broader guide to where to build in public.

Use these four weeks to discover a sustainable routine. The goal is to complete a useful learning cycle, not to meet a publication quota. Move the dates if your project is part-time. A good week can include a small update and a thoughtful follow-up rather than a new post every day.

Choose measurements that connect to your original goal. If you wanted feedback, count relevant conversations and record which decisions they informed. If you wanted beta testers, distinguish volunteers from people who actually tried the task. If you wanted customers, measure the path from a visit to meaningful product use and payment where applicable.

Likes and impressions can tell you something about exposure, but they do not establish product demand. A small number of detailed replies from the right audience may be more actionable than broad attention. Look at the content of the conversations before deciding that a format worked.

For a simple weekly record, write down the post, its purpose, the relevant responses, the decision you made, and the time spent. Add visits, registrations, and activation only when you have a reliable way to measure them. Use tagged links if available, and ask new users how they found you, while recognizing that neither method captures every touchpoint.

A rise in signups after a post does not by itself show that the post caused the rise. Other launches, referrals, product changes, and existing relationships may contribute. Report what you observed, name what you cannot attribute, and use the result to choose the next experiment. That makes a modest result more credible and useful than an unsupported growth claim.

Use the prompts below to turn your current work into a short update. Keep the audience specific, explain one change, and end with a question that can lead to a useful response. Before sharing, check that the draft describes the product’s actual stage and contains only information you intend to make public.

I’m building [product] for [audience].

What changed: [your progress]

What I’m learning: [a lesson or uncertainty]

My question: [one specific question]

If you have nothing to report yet, start with the problem you are investigating and ask how people handle it today. You do not need to invent momentum. An honest question can be a useful first contribution.