Build in Public: Meaning, Examples and How to Start

Build in public means sharing the work on your product while you make it: what you shipped, what broke, what you learned and, if you want, your numbers. Instead of launching in silence after months of work, you post small updates on X, a blog or a newsletter so people follow the story. Done well, it brings you early users, feedback and accountability before the product is finished.

What does build in public mean?

The phrase comes from the indie hacker world, where solo founders and small teams build software without investors. The idea is simple: your audience grows alongside your product, not after it.

A typical build in public post answers one of these:

What did I ship this week?
What did I try that failed?
What decision am I stuck on?
What do the numbers say (visitors, signups, revenue)?

You do not have to share everything. Some people post revenue to the dollar. Others share only screenshots and lessons. The meaning is the same: you let people see the process, not only the result.

If you are new to the scene, start with what an indie hacker is, because build in public is one of the habits that defines it.

Why do founders build in public?

The problem: launching to nobody

The default path for a developer is to build quietly for months, then post a launch and hope. The launch gets a few likes from friends and then nothing.

The cost

You lose months you could have spent learning what people want. You also launch with zero audience, so every first user has to be found from scratch. And you have no one to tell you early that the idea is off.

The fix

Building in public turns the months of work into content. Each update is a small launch. People who follow along become your first testers, your first users and often the ones who share the real launch. You also get feedback while changes are still cheap.

There is a quieter benefit: accountability. When you have said in public that the billing page ships Friday, you tend to ship it Friday.

What are good build in public examples?

A few patterns show up again and again. These are well known and worth studying:

Buffer made transparency part of the company. It publishes its salary formula and writes openly about how the company is run.
Pieter Levels shares the progress and revenue of his projects, like Nomad List, on X. His posts are a template for the short, numbers-first update.
Open startup pages. Many small SaaS products publish a public dashboard with revenue, users and costs. It is build in public as a page instead of a thread.

Here are the formats you can copy, with what each is good for:

Format	What you share	Best for
Weekly update thread	What shipped, what is next	Steady audience growth
Screenshot or short video	A feature in action	Showing progress fast
Numbers post	Visitors, signups, revenue	Trust and curiosity
Mistake post	What went wrong and why	Honest engagement
Decision post	Two options, ask which one	Feedback before you build
Open dashboard	Live metrics on a page	Long-term transparency

My own version is a public build log. I built ten products in about two weeks this October, and a dated list of what shipped is the simplest kind of build in public there is: the work itself is the content.

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

X is where most build in public updates I read get posted, usually under the #buildinpublic hashtag.

A simple setup that works:

Write your bio as a promise. Say what you are building and for whom, in one line.
Post one real update a day or a few a week. A screenshot plus two sentences beats a long thread nobody reads.
Pin your best post. New visitors read your pinned post first, so make it the clearest summary of what you are building.
Reply more than you post. Comments on other builders’ updates are how strangers find you while your own account is small.
Show, then tell. Lead with the image or the number, then the lesson.

A good update follows this shape:

Shipped: dark mode for the dashboard.
Took 3 hours, mostly fixing chart colors.
Next: CSV export, the most requested feature so far.

Short, specific, and it invites a reply.

Share the things that help others or invite feedback:

Features as they ship
Lessons from mistakes
Decisions you are weighing
Traffic and signup trends, if you are comfortable

Keep these private:

Customer data, names or emails, ever
Security details (stack versions, admin URLs, how auth works in detail)
Anything a partner or client has not agreed to share
Revenue, if posting it would stress you or invite copycats you cannot outrun

Copycats are a fair worry. A competitor can copy a feature they see. They cannot copy the audience that follows you or the speed at which you keep shipping.

What are the downsides of building in public?

It is not free. Be honest with yourself about the costs:

Time. Writing updates takes time from building. Keep posts short so content does not replace code.
Performing instead of building. Some people end up optimizing for likes. If your posts are growing and your product is not, that is the warning sign.
Public failure. If the product dies, it dies in front of everyone. An honest post about why it failed is still useful to others, but it stings.
Audience mismatch. If you post to other developers and your customers are dentists, your followers will not buy. Build in public reaches builders first. Make sure some posts speak to your actual buyer.

The fix for most of these is the same: post about the work, not about yourself, and keep the ratio of building to posting heavily on the building side.

How do you start building in public today?

You do not need an audience to start. Everyone starts at zero followers.

Pick one channel. X if your buyers are developers or founders. LinkedIn if they are in B2B. A blog if you want posts that keep getting found through search.
Write a first post that says what you are building and why. One paragraph is enough.
Set a rhythm you can keep. Three posts a week for three months beats twenty posts in one week and silence after.
Reuse the work. A commit message, a bug you fixed, a design you changed: each is a post.
Collect what you learn. Your updates become the raw material for longer blog posts later.

If building in public feels too big, start smaller and learn in public first: share what you are learning instead of what you are selling. It is the same habit with less pressure.

Build in public FAQ

Is build in public only for SaaS founders?

No. Game developers, writers, designers and people making physical products do it too. Anything with visible progress can be shared.

No. Revenue posts get attention, but features, lessons and decisions count just as much. Share what you are comfortable sharing.

How often should I post?

Pick a rhythm you can keep for months. For most people that is two to four short posts a week, plus replies to others.

What if nobody engages with my posts?

That is normal at the start. Keep posting, reply to other builders and treat your updates as a log you will reuse later. The log has value even before the audience shows up.

What is the next step?

Write your first build in public post today, in three lines: what you are building, who it is for, and the one thing you will ship this week. Then post again the day you ship it, with a screenshot.

If you are building alone, read how solo founders handle the rest of the work around the product, and look at the products I built for the kind of progress that makes good posts.