Building in public: what to share and what it gets you

The practice is simple. You keep a running public record of the work, usually as short posts on a social network, a changelog, or occasional longer write-ups. People who follow along see the product take shape and feel some stake in it by the time it launches.

It ranges from a weekly note about what shipped to full financial openness. Buffer is a long-running example of the far end: its Open page publishes monthly revenue metrics, shareholder updates and staff salaries. Buffer is an established company with salaried staff, so treat it as an illustration of how far openness can go. A solo maker can share much less and still get the benefit.

What you can reasonably expect from it:

• Feedback before launch. People tell you what’s confusing while it is still cheap to change.
• A first group to launch to. People who have watched the product grow already know what it is on day one.
• A habit of finishing things. A public weekly update is a deadline.
• A written record. Your own notes on why you chose one approach over another are useful a year later, to you and to anyone evaluating the product.

Decisions and why you made them

These are the most useful posts to read and the ones only you can write. Give the options, the choice and the reason.

• Weak: “Big update shipping soon. Stay tuned!”
• Better: “Dropped the free plan for a 14-day trial. Free accounts were most of my support email and almost none of them upgraded. I’ll report back in a month on what it did to sign-ups.”

Numbers you’re comfortable with

Revenue, sign-ups, churn, traffic, costs. Share the ones you would be happy for a competitor, a customer and a future employer to read, and always say what the number is: the period, the currency, and whether it’s before or after fees and refunds. If you’d rather not share revenue, share something else that’s real, such as how many support requests a release caused.

Mistakes

A pricing change that backfired, an outage, a feature nobody used. Say what happened, what it cost and what you changed. Write these after the problem is fixed and after affected customers have heard from you directly.

Demos

A short screen recording or a before-and-after screenshot of one thing the product now does. Show the product working. A photo of your desk or a screenshot of your to-do list tells a reader nothing about what they could use. The guide on launch listing visuals covers making screenshots and clips that read well at small sizes.

• Customer data. Names, email addresses, company names, support messages and screenshots of real accounts all belong to your customers. Blur or replace them, and check dashboards for names in the corners. Quote a customer only with their permission. Even “just signed our first enterprise customer, a bank in Lyon” can identify someone.
• Security details. API keys and tokens in a terminal screenshot, admin URLs, the layout of your infrastructure, and any vulnerability you haven’t fixed yet. If a secret appears in something you posted, rotate it. Deleting the post is not enough, because copies may already exist.
• Anything under NDA or someone else’s to announce. Client work, partnership talks, an acquisition approach, terms in a contract. If you are unsure whether you may share it, ask the other party first.
• Numbers that mislead. See below.

Numbers that mislead

A true number can still give a false picture, and readers who later work it out will trust the rest of your posts less. Common cases:

• Calling a one-off payment or a lifetime deal “monthly recurring revenue”.
• Multiplying one good month by twelve and calling it annual revenue.
• Reporting revenue before refunds, payment fees and tax as if it were what you kept.
• Reporting total sign-ups when few of those accounts are active.
• A chart with no axis labels, or a cumulative chart, which can only go up.
• Sharing the best day and saying nothing about the trend.

A simple test: would the reader reach the same conclusion if they saw the whole dashboard? If not, add the missing context or leave the number out.

Pick one main place. Splitting short updates across four networks usually means none is kept up.

• A social network your peers or users read. Good for short updates and quick replies. Old posts are hard to find again, and the account sits on a platform you don’t control.
• Your own blog or changelog. Slower to build a readership, but the posts stay on your domain, can be found in search and give other sites something to link to. See getting your first backlinks.
• An email list. A short monthly update to people who asked for it. This is the one audience you can take with you. If you are collecting addresses before launch, read setting up a waitlist.
• Maker communities. Forums and groups where people post progress. Check each one’s rules first. Hacker News, for instance, treats blog posts and newsletters as off topic for Show HN, which is for things people can try (Show HN guidelines).

A workable setup is one social account for short updates, with the longer posts on your own site and linked from there.

Choose a pace you could hold for a year alongside the actual work. For most solo makers that means one short update a week and one longer write-up a month or a quarter. A daily schedule tends to produce posts written because it’s time to post.

1. Keep a running notes file. Add a line whenever you make a decision, ship something or hit a problem. The weekly post is then a matter of picking one line and expanding it.
2. Set a time limit. Half an hour for the weekly update, including replies. If a post is taking an afternoon, it is a blog post, and it should go on your site.
3. Skip a week when nothing happened. An honest gap is better than a post with nothing in it.
4. Reply to people. The replies are where feedback and early users come from.

Watch the ratio of posting to building. If writing about the product is taking more of the week than working on it, cut back the posting.

The people who follow a maker’s progress are mostly other makers. They are interested in how you built it, what you earn and what went wrong. That’s a real audience, and it helps a lot if your product is for developers, founders or other small software businesses, because your followers are also your market.

If you sell to accountants, restaurant owners or teachers, the same audience will like your posts and never buy. You still get feedback on craft, some links and a few people who’ll mention you, but your customers are elsewhere. In that case, spend most of your effort in the places they read, as described in your first 100 users, and keep building in public as a small side habit or drop it.

Other limits to keep in mind:

• Likes and followers aren’t customers. Measure it the way you’d measure any channel: by sign-ups and sales that came from it. Tag the link in your profile so you can tell.
• Competitors read it too. Detailed numbers and plans tell others which ideas are worth copying. Decide how much of that you accept before you start, since posts are hard to take back.
• It can bend your decisions. Once numbers are public, there’s a pull towards choices that make a good post. If you notice it, share less.
• It doesn’t replace a launch. A following helps on launch day, and the preparation is the same either way. The launch checklist covers it.