Guide
Build in public: what to share, and what works
Published · 6 min read
Building in public means showing the work while you do it: what you ship, what you learn, what goes wrong, sometimes the numbers. For a solo maker with no marketing budget, it is often the only marketing there is.
It also has a failure mode that nobody advertises. You can spend a year posting updates, gain a few thousand followers who are other makers, and sell very little. This guide is about doing it in a way that brings users, and about checking that it does.
Why it works when it works
Three things happen when you share the work honestly:
- People see that someone is behind the product. A small tool made by a person who answers is easier to trust than a faceless landing page.
- You get feedback before it is expensive. A screenshot posted on Tuesday can save you a week of building the wrong thing.
- Each post is a small door. Any one of them is unlikely to matter. Fifty of them, tagged and spread over a year, are fifty ways to find you.
None of this is guaranteed, and none of it is fast. Building in public pays the way a savings account does.
Who you are talking to
This is the question that decides everything else, and the one most makers answer by accident.
If you post about revenue milestones, pricing experiments and launch tactics, your audience becomes other makers. They are generous with likes and advice. Unless your product is for makers, they are not your customers.
If you post about the problem your product solves, your audience becomes people who have that problem. They react less, and they buy more.
Both audiences have value. Other makers give you reach, feedback and company. Just be clear about which post is for whom, and do not judge a post written for customers by the number of makers who liked it.
What is worth sharing
A list you can rotate through, so that you never start from a blank page:
- What you shipped, shown. A recording, a before and after.
- A decision and its reason. Why you removed a feature, why you chose a price.
- A mistake. What it cost and what you changed. These are the posts people remember.
- A customer problem, with their permission and without their name. How they were doing it before.
- A number with its context. Not "we hit a milestone" but what moved, why you think it moved, and what you will try next.
- A question you cannot answer yet. Real ones. People can tell.
The guide on announcing a feature on X, LinkedIn and Reddit has templates for the first item.
What to keep to yourself
Openness is not the same as publishing everything.
- Anything about a customer they have not agreed to share: names, messages, screenshots of their data.
- Secrets and anything that leads to them: keys, internal addresses, an unblurred dashboard.
- Numbers you would be uncomfortable seeing quoted in a year, or by a competitor. Revenue is yours to share or not. Many makers share growth and keep the totals private.
- Complaints about a named person or company. They age badly.
- Promises with dates. Share what is done. "Next week" has a way of becoming next quarter in public.
A rhythm you can hold
The makers who get something out of building in public are rarely the loudest. They are the ones still posting in month eight.
- Tie posts to work you are already doing. A release, a decision, a support conversation. If posting needs a separate block of time, it will lose to the product every week.
- Pick a floor you can keep on a bad week. Two posts a week for a year beat a daily streak that ends in March.
- Write it down when it happens. Keep one note where you drop screenshots and one-line observations. On posting day you choose from the note instead of inventing.
- Use your releases as a clock. If you ship every week, that is one post a week already. Your release notes are a first draft; GitHub explains how releases work if you do not publish them yet.
The trap: an audience is not a customer base
Follower counts go up and to the right, and they feel like progress. So it is easy to optimize for them: more milestones, more hot takes, more of whatever was liked last time.
The check is simple. Every few weeks, ask:
- How many visitors did my posts send to the product?
- How many of them signed up?
- How many of those paid?
If the first number is large and the third is zero for months, you are building an audience for your posts, not for your product. That can still be worth doing, but you should know it is what you are doing.
How to measure it without turning it into a job
You do not need a dashboard habit. You need each post to carry its origin, and a look once a week.
- Tag every link, one short tag per post:
yoursite.com/?ut=x-pricing-lesson. The guide on UTM links for indie hackers covers naming. - Tag your profile link separately. A lot of build-in-public traffic comes from people who liked a post and clicked your name.
- Log posts that have no link with their date. Some of your best posts will be screenshots with no link at all. upTake estimates their effect from the traffic their channel sent in the following 72 hours, and marks it as estimated.
- Connect your payments so that the weekly view goes all the way to revenue. Without that, you are comparing visits, which is only slightly better than comparing likes.
Then, once a week, sort your posts by what they brought. The top of that list tells you what to do more of. The bottom tells you what to stop, which is often the more useful half.
When the numbers say it is not working
Give it time before judging: a handful of posts proves nothing in either direction. But if after two or three months your posts send visitors who never sign up, change one thing at a time:
- The audience: write for people with the problem, not for people with a product.
- The place: a different platform or community, where those people already are.
- The landing: send each post to a page that continues its sentence, not to your home page.
- The ask: make the next step obvious and small.
If nothing moves, building in public may simply not be how your customers find products. Some markets buy through search, through directories, through a colleague's recommendation. That is a useful thing to learn in three months instead of three years.
The short version
- Share the work, the decisions and the mistakes, shown rather than described.
- Know which posts are for makers and which are for customers.
- Keep customer data, secrets and dated promises out of it.
- Choose a rhythm you can hold in a bad week.
- Tag every link, and judge posts by signups and payments, once a week.
Building in public is a habit that compounds slowly. Measuring it is what keeps the habit pointed at users.
See this in upTake
Pick one visible change from To post. Write why it matters to the user, then return to its recorded results before choosing the next update. The example is a release announcement, not a customer case study.