Build in Public, Done Right: What to Share, What Not To, How to Measure It

The short version, before the detail:

• Building in public is sharing the making of a product, not only the launch.
• None of the three guides read for this page gives a measured result, so the benefits are claims to test.
• Before any post, ask two questions: does it identify a customer, and does it expose work a competitor could use?
• Count conversations and tagged signups. Record followers and likes, and never decide on them.
• Set an hours budget and a stop rule before you start.

What is building in public?

That definition follows Paddle's guide to the build-in-public strategy, which calls the phrase fairly new. The guide names Twitter as one place founders do it and lists Instagram, TikTok, Snapchat, Reddit and Indie Hackers as others.

A related term in the same guide is the open startup, a company that openly shares its metrics and how it earns its money. Building in public does not require that. You choose what to open.

The phrase also appears in unrelated fields, such as capacity building in public health and image building in public relations. Those are different subjects, and this page covers only the founder practice. Each community where founders post has its own rules, which a guide to communities beyond Reddit covers.

Does building in public work?

The sources read for this page do not show that it does, because none of them reports a measured result. Every benefit is stated as a claim, and the table below sets each claim beside the basis the page gives for it.

The table was built from the three guides and four community threads in the research package. The criteria were who states the claim, what basis the page shows and what the claim actually measures.

It supports one narrow conclusion: founders do this for reasons that are easy to name and hard to verify. buildinpublic.xyz tells a story of growing from 400 to more than 35,000 followers, but a follower count says nothing about revenue. The practical reading is to run it as a bounded test.

Community threads show the same doubt from the other side. One r/SaaS thread asks who has actually won paying customers from build-in-public content, and an r/buildinpublic thread raises engagement mistaken for traction and the hours that posting consumes. They show what founders ask, not how often any outcome happens.

What should you share when you build in public?

Share what a reader can use or check: what you shipped, what you learned, what went wrong and was fixed, and numbers you chose in advance. Paddle's guide suggests four kinds of material: screenshots and quotes from customer feedback and other communication channels, real company stories with the roadblocks included, insight into the roadmap and how the company runs, and previews of new features on Product Hunt.

Look at that list again. Customer feedback, internal threads, the roadmap and launch previews are the places where a post can expose someone else. The checklist further down exists for that reason.

A starting share list, which is Kanso's suggestion and not a published standard:

• A change you shipped, with what it replaced.
• A decision you made and the reason, once the decision is final.
• A mistake, after it is fixed.
• A number from a metric list you chose in advance.
• A question you will act on, put to the people you want to hear from.

Write the list down before the first post. A written list makes the decision once instead of every time you are tempted.

What should you not share when you build in public?

Do not share anything that identifies a customer without their agreement, anything that tells a competitor what you will ship before you ship it, or anything you could not defend if the person concerned read it. None of the sources read for this page sets a rule here, so this section is Kanso's analysis.

• Customer names, faces, emails and account details.
• Screenshots of internal chat and support tools, unless you recreate the content.
• Contract terms, or a price agreed with a single customer.
• Security problems that are not fixed yet.
• Launch dates you do not control.
• Claims about named competitors that you cannot support from a public page.
• Anything about your team that they have not agreed to share.

Call this the never-share list and write it next to the share list. Post from the two lists, and add to the second whenever a post goes wrong.

How do you check a post for competitor and customer risk?

Find the row that matches the post, then apply its check before you publish. The table maps the material Paddle says founders share to the risk it carries for customers and for competitors.

The rows come from the kinds of material in Paddle's guide, with opinions about named competitors added because founders post them. Each risk is reasoned from what the post would show, and none is drawn from a case study. The pages read contain no data on how often sharing helps a rival or harms a customer.

Protecting customers

Ask before you use a customer's words or screen, show only what the post needs, and remove anything that identifies them. Customer feedback is the first item on Paddle's list of things to share, so this is where most founders will start.

1. Ask first, in a message you can find later.
2. Crop or recreate the screenshot so only the point remains.
3. Describe the problem, not the person.
4. Remove names, avatars, emails, account numbers and anything else in the corners of the image.
5. Remove a post at once if the customer asks, and tell them it is gone.

This is a business practice, not legal advice. Contracts and privacy rules differ by customer and by country, so check your own.

Limiting what rivals learn

Nobody has measured how much a public build helps a competitor, so the answer is reasoning: the exposure is largest for what a rival could not easily see for themselves. Unannounced features and dates, what each channel costs and returns, pricing experiments and the segments that respond are higher exposure. Shipped features visible in the product, public pricing and lessons about process are lower.

If you post about a named rival, keep each claim to what a public page shows and date it. A competitor analysis template with evidence columns separates what you observed from what you inferred, which is the discipline a public post needs too.

The five-question pre-post check

1. Could anyone name a customer from this post, including from a logo, the corner of a screenshot or a timestamp?
2. Did that customer agree to this use?
3. Does it show a date, a number or work that a competitor would otherwise have to guess?
4. If you change course, would anyone who relied on this be let down?
5. Would you post it if the person concerned read it tomorrow?

A yes to the first, third or fourth question means the post needs changing. The default fix is to rewrite it, not to drop it.

How do you build in public on X (Twitter)?

On X, founders mostly post short updates and threads, and Paddle's guide sorts the thread styles into ten formats. The table lists eight of them with the checklist risk each one carries. The risk column is Kanso's mapping.

Paddle also describes diary-style threads and curated lists of a founder's best threads. They carry the same risks as the rows above. Paddle says Twitter throughout and the one dated example in the text read is from January 2022, so check that a format still works before you copy it.

Platform risk is real. buildinpublic.com says the #buildinpublic community reached 250,000 members on X Communities and that X has announced it is shutting that product down. The page does not claim the shutdown has happened, and it says an X account is needed for now to claim a profile in its directory.

The lesson, in Kanso's reading, is to keep a list you own, such as an email list. Whether X is worth the time at all is a separate question, which an evidence review of X for B2B SaaS checks figure by figure.

How do you build in public on LinkedIn?

On LinkedIn the main risk is audience, not format, because your connections may have joined your network for reasons that have nothing to do with your startup. A startups thread raises exactly that worry: posting founder content in a way that feels out of place to colleagues who did not follow for it.

The same thread leans toward a second profile only when the first creates genuine risk or constant confusion. Kanso's reading is that it is a heavy answer, and it is worth trying a change of topic first, tying each post to the work your connections already know you for.

LinkedIn posts are also where customer and employer details leak most easily, because the audience includes both. A posting system built from your actual work logs commits, customer calls and decisions and screens them before drafting, which fits the pre-post check above.

How do you measure building in public?

Measure it against what you set out to get: conversations and tagged signups for customers, product changes for feedback and hours for cost, and keep followers and likes as context only. The table maps each benefit Paddle names to something you can count.

The table was built by taking Paddle's six benefits, dropping those with no observable count and adding cost, which the community threads flag as the hidden price. Trust has no reliable count, so it is left unmeasured on purpose.

Tag the links you post with a source, medium and campaign so a signup can be traced to a post. A UTM naming convention that survives a year shows how to name them. Then keep two columns apart: activity (posts, likes, followers) and outcomes (conversations, signups). The threads read for this page describe engagement being mistaken for traction, and the two columns stop that.

Review the counts alongside your other numbers each week. Seven weekly marketing numbers for a seed-stage founder sets out a review the build-in-public counts can join.

A worked example with hypothetical numbers

Divide your hours by the outcomes they produced: with the hypothetical inputs below, 32 hours produced 11 conversations and 3 tagged signups, which is 2.9 hours per conversation and 10.7 hours per signup. These numbers are invented to show the arithmetic. They are not a benchmark and not a result.

The figure only means something against a baseline. Run the same hours calculation for another channel in the same period, such as direct outreach, and compare. One thread read for this page describes shifting time toward talking directly with people who already have the problem, and customer research in a week sets out ways to do that.

What is a sensible eight-week plan, and when should you stop?

Run it as an eight-week test with an hours budget, a written share list and a stop rule, then decide from the numbers. Eight weeks is Kanso's suggestion, long enough for eight weekly reviews, and has not been tested.

1. Week 0: write the share list and the never-share list, pick one platform, set the weekly hours budget, create tagged links and record your starting numbers.
2. Weeks 1 to 8: post on the days you chose, run the pre-post check on every post, and log hours and conversations once a week.
3. Week 4: compare hours with the budget. If you are over it two weeks running, post less often, not less carefully.
4. Week 8: work out hours per conversation and per signup, compare with another channel, and decide to continue, change the format or stop.

Stop rules, also Kanso's suggestions:

• Change the format or stop if eight weeks produce no qualified conversation.
• Never publish a post that fails the check. Rewrite it or drop it.
• If a product problem is what buyers are reacting to, fix the product before posting more about it.

What is documented and what is analysis?

The documented items are statements made by the pages read on 6 November 2026, and the analysis items are Kanso's own reasoning. The split is here so you can weigh them differently.

Documented, per the sources:

• Paddle defines building in public, lists six benefits, four ways to do it and ten thread formats, and describes the open startup.
• buildinpublic.com says the #buildinpublic community reached 250,000 members on X Communities, which X has announced it is shutting down.
• buildinpublic.xyz tells a follower-growth story and publishes testimonials, on a site that also sells consulting and advisory work.
• Four Reddit threads raise questions about paying customers, engagement versus traction, time cost and audience fit.
• None of the pages reports a measured result, a customer acquisition rate or a case of harm to a competitor or customer.

Kanso's analysis:

• The risk checklist, its checks and its safer defaults.
• The reasoning about which material gives a rival the most.
• The measurement plan, its mapping from benefits to counts and its two-column rule.
• The worked example, whose numbers are invented.
• The eight-week plan and the stop rules, which have not been tested.

Where does Kanso fit?

Kanso's X (Twitter) Agent drafts X posts from your marketing context, and its LinkedIn Agent drafts founder-voice LinkedIn posts the same way. You edit and publish both yourself. Kanso does not auto-post and does not schedule X or LinkedIn posts, so the pre-post check stays your job.

Plans and what they include are on the pricing page.

Build in public: frequently asked questions

Sources

• Build-in-public strategy: Benefits + 10 examples, Paddle
• Build in Public, buildinpublic.com
• The future belongs to those who dare to build in public, buildinpublic.xyz
• The uncomfortable truth about "build in public" that nobody ..., Reddit, r/SaaS (used only for the questions it raises)
• Don't build in public, it's killing your startup (and no one ..., Reddit, r/buildinpublic (used only for the questions it raises)
• Hot take: "build in public" is the most overrated advice of ..., Reddit, r/SideProject (used only for the questions it raises)
• Build in Public got me attention, but I think it pulled ..., Reddit, r/startups (used only for the questions it raises)
• X (Twitter) Agent, Kanso
• LinkedIn Agent, Kanso