Is Building in Public Worth It? (2026 Guide)

What build in public means

Building in public means doing the work of a startup where people can watch. Instead of building quietly for six months and then announcing a finished product, you post as you go: why you picked this problem, what you decided this week and why, what a user said that changed your mind, how many people signed up, and what went wrong.

Three things separate it from ordinary marketing:

• It is about the process, not the product. A launch post says "here is the thing". A build in public post says "here is what I learned making the thing".
• It is ongoing. One post is an announcement. Building in public is a habit, usually weekly, kept up for months.
• It includes the bad weeks. Posts about a wrong guess or a flat week are part of the deal, and often the ones people remember.

You do not have to share everything. How much you share is a choice, and you can change it later.

Where building in public came from

The phrase is recent. The practice is not.

• Buffer, 2011 and 2013. In February 2011 Joel Gascoigne published Idea to Paying Customers in 7 Weeks, the first of a series he called "Building Buffer". Before writing the product, he put up a two-page site, "simply tweeted the link and asked people what they thought of the idea", then added a pricing page between the two to see who would click a paid plan. In December 2013 Buffer published every salary in the company and the formula behind them. Its open page still shows revenue, salaries and a company history that includes the 2016 cash-flow crisis and layoffs.
• Pieter Levels, 2014. On 1 March 2014 Levels posted I'm Launching 12 Startups in 12 Months, a public commitment to finish and ship. He has written that Nomad List started in 2014 as part of that goal, growing out of a crowdsourced spreadsheet.
• Baremetrics and Open Startups, 2014 to 2015. Baremetrics made its own revenue dashboard public, Buffer followed, and on 22 April 2015 Josh Pigford announced the Open Startups initiative with seven companies: Baremetrics, Buffer, ConvertKit, Ghost, Hubstaff, Promoter and StoreMapper.
• Indie Hackers, 2016. Courtland Allen started Indie Hackers in July 2016 to put profitable small online businesses in the spotlight, through interviews with founders earning "from a few hundred to tens of thousands of dollars per month", as TechCrunch reported when Stripe acquired it in 2017.
• #buildinpublic, around 2020. The hashtag spread on Twitter among indie makers. The r/buildinpublic subreddit was created in September 2020 and had about 128,000 members on 31 October 2026, and Karthik Puvvada (KP) hosts the Build In Public Podcast.

Notice that Buffer's first public posts came before there was a product to sell. Building in public started as a way to test an idea in front of the people who might use it, not as a way to show off revenue.

Is building in public worth it?

Short answer: yes if your buyers read the places you post and you can keep going for three months; no if they don't, or if posting eats your build time.

The honest answer depends less on how well you write and more on who is reading.

When it works

Building in public works when four things are true:

1. Your buyers read the platforms you post on. Developer tools, maker tools, products for founders, marketers and creators: these buyers hang out on X, Indie Hackers, Reddit and LinkedIn, and many enjoy watching products get built. Jason Leow, who builds in public himself, puts the fit plainly in Building in public is overrated: it works when you are "building for fellow makers who are active Twitter users".
2. You can keep going for months. The first month is mostly silence. The value comes from the people who have followed for ten or twelve weeks and trust that you ship.
3. Your edge is not the idea. If your advantage is your skill, your relationships or your speed, showing the work costs little. If it is a single clever idea anyone could rebuild in a weekend, showing it costs a lot.
4. You enjoy writing about your work. If it feels like homework, you will stop in week three.

When those hold, you get feedback before you build the wrong feature, accountability that makes you ship, and a launch day where somebody is already listening.

When it does not

Skip it, or keep it small, when:

• Your buyers are not there. A procurement manager at a hospital does not follow founders on X. For enterprise and many local businesses, posts reach other founders and nobody who will sign a contract.
• You work in a regulated or confidential space. Health, finance, legal and security products often cannot show customer stories, data or even screenshots.
• The market is crowded and easy to copy. If ten teams are building the same thing, a detailed post about what is working is free research for nine of them.
• It eats build time. If you spend more time on posts than on the product or on talking to users, the posts are winning and the company is losing.
• You need to look large. Some buyers want an established vendor, and posts about a one-person company's bad week work against you.

Run your idea through this before you commit:

Four or more answers in the middle column: build in public. Three: try it for twelve weeks with a fixed time budget and judge it by signups. Two or fewer: put the same energy into direct outreach or communities where your buyers ask for help, and post occasionally.

The risks, and what to do about each

None of these risks is a reason never to build in public. Each has a simple way to limit it.

Copycats are real, and usually less damaging than they feel. In February 2021 Arvid Kahl wrote about a founder whose product was cloned, complete with a comparison page attacking the original. His view: "It takes an afternoon to (badly) clone an existing business", but "they can't copy you, just your work". The founder kept building in public. The practical line most founders draw: the problem, your reasoning and what you learned are safe to share; your exact customer-acquisition playbook, your unreleased roadmap and your customers' details are not.

Revenue is optional, and many founders dial it back. Bannerbear's open page now reads that it "was an open startup with public metrics, we now only share selected metrics". Before launch this question barely matters: you have no revenue, so you share signups, replies and lessons, which help you more anyway.

The biggest risk is the quietest one: an audience of peers. Other founders like, reply and repost each other's updates, which feels like traction. Check who is actually replying. If it is mostly people building their own products, and you are not selling to founders, you are writing to the wrong room.

Posts to share before you have a product

What to post when building in public: 8 post types

This is where most founders stall: there is no product yet, so what is there to say? More than you think. The stage before launch has the most interesting material, because everything is still being decided. Arvid Kahl's guide on what to share at which stage puts how you validate assumptions and how you adapt the idea to customer feedback first on the list for this stage. If you are still testing the idea, these idea validation tools give you plenty to report.

Here are eight post types, what each one is for, and an example you can adapt. Replace everything in [brackets].

1. The problem and why you care

Your first post, and one you can repeat every few months in new words. Describe the problem the way the person who has it would, with a real detail. People who have the problem will recognize themselves; everyone else will scroll past, which is fine.

I'm a [role] and I lose about [3 hours] every [week] to [task].

The tools I tried either [do too much / cost too much / miss the one thing I need]:
[specific example].

So I'm building [product], something that does just [one job].

If you also [do task], I'd love to hear how you handle it today.

2. A decision and the trade-off

Founders make dozens of decisions a week: what to build first, what to charge, which stack, who it is for. Explaining one, including what it costs you, invites people to poke holes before you commit, and shows how you think.

Decision this week: [product] will only support [platform/use case] at launch.

Why: [7 of 10] people I talked to use [platform]. Supporting [other option] would
add [6 weeks].

What it costs: I'll have to turn away [type of user] for now.

Would this rule you out? Tell me, I'm still deciding what comes second.

3. What a user interview taught you

Interviews are the best material you have, because nobody else has it. Share the lesson, not the person: no names, no identifying details, and ask permission before quoting anyone.

Talked to [8] [role]s this week about how they [do task].

What I expected: they want [feature I planned].
What they said: "[short paraphrase of a real pain]."

[6 of 8] described the same workaround: [workaround].

Changing the first version because of it: [specific change].

4. Your numbers, even small ones

Small numbers shared honestly beat large numbers implied. "37 signups" is more believable, and more interesting, than "huge interest". Pick the two or three numbers that matter at your stage and report them on the same day every week.

Week [6] update for [product]:

- Waitlist signups: [37] (+[12] this week)
- Where they came from: [Reddit 15, X 11, newsletter 7, LinkedIn 4]
- Interviews booked: [2]
- What I shipped: [one thing]

Best signup source this week: [a post in r/subreddit about topic]. Doing more of that next week.

5. A failure or a wrong guess

These are often the posts people remember, because they are rare and useful. Say what you assumed, what happened, and what you will do differently. Keep it factual: a lesson, not a confession.

I spent [2 weeks] building [feature] because I was sure [assumption].

I showed it to [5] people. [4] asked "what is this for?"

What I missed: [real reason].

Lesson: [one sentence]. Next time I'll [show a sketch / ask first] before building.

6. A screenshot or design in progress

Unfinished work is relatable and gets specific feedback that polished work never does. Show two options and ask a narrow question, so people can answer in one line.

Two versions of the [signup / dashboard / pricing] screen for [product].

Left: [what it does]. Right: [what it does].

If you [do task], which one would you understand in 5 seconds? Why?

[image A] [image B]

7. A milestone with a thank-you

Milestones give followers a reason to celebrate with you and a moment to share. Pair every milestone with what you learned getting there and credit the people who helped.

[100] people have joined the waitlist for [product]. [5] weeks ago it was zero.

What worked: [channel] ([N] signups), [channel] ([N]).
What didn't: [channel], [N] posts, [N] signups.

Thank you to [names, with permission] for [what they did]. Next: [next goal].

8. A direct ask

The post most founders forget. Followers want to help and rarely get asked. Be specific about who you need and what they get, and send them to a page that collects their answers, such as an idea validation landing page with a question or two on the form. If the ask is for testers, our guide to finding beta testers has screening questions and messages to copy.

Looking for [5] [role]s who [do task] at least [weekly].

You'd get: [early access / a founding price / a say in what I build next].
I'd ask for: [a 20-minute call / 2 weeks of use and honest notes].

Reply or DM me, or join here: [link]

What to keep private

• People's details. No customer or interviewee names, screenshots of private messages or identifiable stories without written permission.
• Security and infrastructure details an attacker could use.
• Your exact acquisition playbook while it is still working.
• Unreleased plans a competitor could ship first.
• Fundraising in progress. Talk about it once it is done.
• Made-up or rounded-up numbers. If a number would embarrass you when someone checks, do not post it.

A weekly cadence that fits in three hours

The founders who get results are the ones still posting in month four, which is a scheduling problem more than a writing problem. A plan that fits in about three hours a week:

Two posts a week is enough. The hour of replying matters as much as the posts: in the first months your own posts reach almost nobody, so thoughtful comments on other people's posts are how most people first see your name.

Give it twelve weeks before you judge it. Write the date in your calendar now and decide then, against the numbers in the measuring section below, whether to keep going, switch platforms or stop.

Build in public on X, LinkedIn and five other places

Pick one main platform where your buyers are, and at most one more. The same text pasted everywhere reads as spam.

X

X is where #buildinpublic became a habit, and it is still where many founders, developers and makers post their progress. Short posts with a screenshot or a number do well; threads work for a lesson with several steps. On links, the record is mixed: Elon Musk said in late July 2026 that X had not limited link posts "for over a year", while PPC Land's analysis reported link posts getting 94% fewer views than comparable posts without one (PPC Land, July 2026). Many founders keep the link in their bio and pinned post and add it in a reply. Try both and compare your own signups.

LinkedIn

LinkedIn calls itself the world's largest professional network, with more than 1 billion members. That makes it the better choice for B2B products where the buyer has a job title. What works there is less "week 6 MRR" and more "here is what 12 finance managers told me about month-end close". Write about your buyer's problem in their words, and your posts reach people who have it.

Indie Hackers

Indie Hackers is a community of founders sharing posts, case studies and products. Long, honest posts with real numbers and a clear question suit it best. It is a good place for peers, advice and accountability, and a weak place to find customers unless your product is for founders.

Reddit

Reddit is many separate communities, each with its own rules. As of 31 October 2026, r/SideProject had about 887,000 members and asks that project links be titled "[Project name] - [Short description]"; r/indiehackers had about 199,000. Those reach other builders. The bigger win is the subreddit where your buyers ask for help: answer questions there for weeks before you mention your product, read the rules, and say plainly that you are the founder.

Bluesky and Threads

Both are worth a test if your buyers are there. Bluesky has starter packs, lists of up to 150 people and 3 custom feeds that anyone can create and share, so getting into your niche's pack puts you in front of everyone who follows it. Threads allows one topic tag per post, and tags can include spaces, so picking the right tag decides who finds you.

Your own newsletter

Every platform above can change its rules or its algorithm. An email list cannot be taken away. Tony Dinh, a full-time indie hacker who describes himself as very active on X, also sends monthly updates by email about what he built and learned, to what his page says is more than 15,000 subscribers. You do not need a newsletter tool to start: a waitlist landing page that collects emails and a short update every week or two are enough.

How to turn followers into signups

Followers do not become signups by accident. Three things move them:

1. One link. Every post, bio and pinned post points to the same place, usually a pre-launch waitlist. Not your X profile, not a Notion doc, not three different links. One page.
2. A page that says what it is in one line. Who it is for, what it does, what happens when they join. If you need ideas, look at waitlist landing page templates built for exactly this.
3. A clear reason to join now. Early access before everyone else, a founding price, a say in what gets built, a seat in a small first group. "Stay updated" is not a reason.

Then close the loop: a welcome email right away, then a short update whenever you post something big, with a line about what it means for them. Our waitlist email templates include a founder update you can adapt.

Give the people who joined something to do. A referral waitlist gives each signup a link to share and shows their queue position moving when friends join, which turns your followers into people who post about you. If signups are arriving but nobody is converting later, read why your waitlist is not converting before posting more.

Building in public is one channel. For the others, see how to promote your waitlist across 15 channels, the places to promote your startup for free and, for launch day itself, where to launch your startup. If you are still at zero, the guide to your first 100 waitlist signups covers the first weeks step by step.

How to measure building in public

Likes and followers tell you whether people find your posts interesting, not whether building in public is working for your business. One Indie Hackers post sums up the gap in its title: 103 free tools and a Short every day for 26 days, "traffic doubled, sales are still $0".

Track these instead, every Friday:

The source tag is the most useful habit on this list. Use a different link per platform (yourpage.com/?source=reddit, ?source=x, ?source=newsletter) and after a month you know which posts and platforms brought signups, not just applause. For more on setting up the numbers, see waitlist analytics.

Set a bar before you start. A reasonable one for a pre-launch product: after twelve weeks, a steady weekly trickle of signups from your target buyer, and at least a few conversations a month that came from posts. If you are nowhere near that, change the platform or the content before you change the volume. Our SaaS pre-launch marketing playbook shows how building in public fits next to other channels over 90 days.

Build in public examples worth studying

Each of these shows a different way to do it, with facts from the founders' own pages.

• Buffer: building in public before the product existed. The 2011 post describes a two-page test tweeted to followers, a pricing page added to test willingness to pay, and a launch on 30 November 2010 with the first version built "in evenings and weekends over a period of 7 weeks". Two and a half months later it reported more than 500 users and about 4% upgrading to paid. Buffer kept going in public, bad news included: its open page lists the 2016 cash-flow crisis and layoffs next to the wins.
• Pieter Levels: public commitment as accountability. His 12 startups in 12 months post is a lesson in using an audience to force yourself to ship. He wrote it partly in frustration at startups that, a year on, were "still the same landing page collecting beta emails". A waitlist is a start, not a substitute for shipping.
• Bannerbear: choosing to share less. Its open page links milestone posts from zero to $10k MRR and beyond, and says it now shares only selected metrics. Dialing back is allowed.
• Marc Lou: one page for everything. His site lists the products he has built, most with their monthly revenue, all on one page, so every post can point to the same place.
• Tony Dinh: the newsletter as the base. Alongside his posts on X, he sends a monthly email about what he built and learned, so his readers do not depend on any one platform.
• Arvid Kahl: from one exit to the next, in public. He built FeedbackPanda, which grew to thousands of customers before it was acquired, wrote the book about it, and now writes about building Podscan in public on his site.

What none of these examples show is a founder who grew an audience first and figured out the product later. In every case the posts were about real work: a test, a product, a number, a decision.

Where LaunchList fits

LaunchList is pre-launch waitlist software for founders. It will not write or schedule your posts, find your followers or make building in public work if your buyers are not reading. What it does is give your posts somewhere to send people and a way to keep talking to them once they arrive.

• One link for every post. A hosted waitlist page written from one sentence and then edited block by block in the waitlist page editor, live at your own launchlist.page address. Or put a waitlist signup form on a site you already have.
• Know which platform each signup came from. Add a hidden field with the key source and every link you share as ?source=x or ?source=reddit records the platform on each signup, on every plan. The breakdown of signups by channel and referring site in Analytics is on the Grow plan.
• A public updates page for your progress. LaunchList Updates is a build in public changelog: short posts on a public page with RSS, which can also show on your Launch page and each signup's status page. It is on every plan, and publishing never sends an email on its own.
• Email your list the updates you post. From the Collect plan you can email your waitlist, including turning an update into an email draft you check and send. The pricing page shows what each plan includes.
• Followers who bring friends. Every signup gets a referral link and a live position on every plan, so the people who follow you can move up by sharing.

When the waitlist is big enough to let people in, our guides to running an early access program and to convert a waitlist into paying customers pick up where this one ends.