Build in Public: A Practical Guide for Founders

What building in public means

To build in public is to share the work of building a company while it is happening: what you are shipping, what you learned from customers, what went wrong, and often how much revenue the product is making. The audience is usually other founders, potential customers, and people who follow your niche. The channel can be a blog, a newsletter, a community forum, social media, or a public metrics page.

Building in public is not a growth hack. It is a publishing habit with real benefits and real costs. Done well, it produces a record of decisions and results that earns trust over time. Done badly, it becomes vanity posting, invites copycats, or leaks information that customers and future buyers would rather you kept private.

This guide covers what to share, what not to share, how to make updates credible, and how to decide whether building in public suits your business at all.

Where the practice comes from

Public transparency among software startups became visible around 2013 and 2014. Buffer's open page states that the company has been open with its finances and salaries since 2013, and it still publishes a metrics dashboard, salaries, and shareholder updates. Baremetrics made its own revenue dashboard public and later launched its Open Startups page listing companies that share metrics openly; a 2015 VentureBeat article described the launch with seven participating startups.

Since then, "build in public" has broadened. Many founders who never publish a full metrics dashboard still post weekly progress threads, changelogs, and milestone notes. Plausible Analytics is a well-documented example of the lighter-weight form: co-founder Marko Saric wrote that early users came mainly from updates posted on Indie Hackers, Twitter, and the company blog, and that the company has published its own website traffic publicly from the start.

The related idea of an open startup, where a company publishes core financial metrics on an ongoing basis, is covered in the open startup guide. Building in public is the broader habit; an open startup is one specific, more data-heavy form of it.

Why founders build in public

There are four honest reasons to do it.

Distribution when you have none. An early-stage product has no audience. Regular, specific updates give people a reason to follow along before they need the product. Paul Graham's essay Do Things That Don't Scale argues that founders have to go out and get early users rather than waiting for them; posting your progress where your future customers already gather is one way to do that.

Feedback from the right people. Posting a half-finished feature or a pricing question invites responses from people who care about the problem. That is cheaper than formal research, though it is biased toward people who enjoy commenting.

Accountability. A public weekly update forces you to ship something worth writing about. Many founders find that useful during the long, quiet stretch before revenue.

Trust with customers and buyers. A history of consistent, specific updates is evidence. It shows how you make decisions, how you handle setbacks, and whether the business you describe today matches what you said six months ago. If you ever sell the company, that record can help a buyer understand its trajectory, as long as it agrees with the private data.

What to share

Useful public updates are specific and repeatable. A good weekly or monthly update often includes:

What shipped. Features, fixes, and the reason for each one.
What you learned. A customer conversation, a failed experiment, a channel that did or did not work.
Key numbers, clearly labeled. Revenue, paying customers, signups, or churn, each with a stated definition and period.
What is next. One or two priorities for the coming period.
Mistakes. Outages, bad launches, pricing errors. These tend to be the most read and the most useful to others.

On numbers specifically, label everything. "Revenue" in a tweet can mean gross volume, subscription MRR, trailing 30-day revenue, or net payouts. Each is legitimate, but they are not interchangeable. If you report MRR, make sure it excludes one-time sales and normalizes annual plans; the what is MRR guide explains the calculation. If you report trailing revenue, say so.

What not to share

Building in public does not mean publishing everything. Keep the following private:

Customer data. Names, emails, company names, and per-customer amounts, unless the customer has explicitly agreed. In a small niche, even "a dentist in Leeds just signed up" can identify someone.
Credentials and infrastructure details. API keys, admin URLs, and screenshots of dashboards that show account IDs or configuration.
Security issues before they are fixed. Write the postmortem after the patch, not during the incident.
Unverified claims. Do not post projections as if they were results, and do not round up.
Things you promised to keep confidential. Partner terms, acquisition conversations, and investor discussions.
Your exact playbook, if it is your only moat. If your growth depends on one keyword cluster, one marketplace listing, or one partner, publishing the details can invite competitors into a channel you cannot defend.

That last point deserves weight. Plausible's founders have argued that openness is not a disadvantage for them, but they compete on trust in a privacy-sensitive market where transparency is part of the product. A small niche tool with a simple, copyable idea may face a different calculation.

How to make public updates credible

The biggest weakness of building in public is that most claims cannot be checked. Screenshots are easy to edit, and readers know it.

Credibility comes from three habits:

Consistency. Use the same metric definition every time, publish on a regular schedule, and keep posting when numbers go down. A founder who only posts good months is giving a selective sample.
Specific definitions. State the period, what is included, and whether figures are before or after refunds and fees.
Independent evidence. Link to a source the reader can check rather than an image you produced.

Verified revenue helps with the third habit. On RevenueBug, you connect a payment provider such as Stripe, and the public profile shows a daily revenue graph and trailing 30-day revenue calculated from the provider's data. You can then link to that profile, download a PNG card for social posts, or embed the card on your site. The guide to showing Stripe revenue on your website explains the sharing options in detail.

Be precise about what that verification means. The methodology page explains that "verified" means calculated from a connected provider's data. It is not an audit, proof of profitability, or proof of ownership. It does make it much harder to post a number that the underlying payments do not support.

If you want the accountability of public revenue without naming the product yet, anonymous mode hides product identity while keeping revenue visible. That can suit founders who want to share progress before they are ready to reveal what they are building.

A simple build-in-public routine

A sustainable routine matters more than a perfect one. A workable starting point:

Weekly: a short update on one channel your customers actually use, covering what shipped, one lesson, and one number.
Monthly: a longer post with a consistent set of metrics, a short narrative, and what you plan to do next month.
At milestones: first paying customer, first 100 customers, a pricing change, or a major launch. Explain what led to it.
When things break: a short, factual postmortem once the problem is resolved.

Pick one primary channel. Spreading updates across five platforms usually produces five weak feeds instead of one strong one. Plausible's experience suggests that a community of other builders, such as Indie Hackers, can be a supportive starting point, but your long-term audience should include people who might buy the product, not just other founders.

When building in public is a bad fit

Building in public is optional. It may be the wrong choice when:

Your customers are not on the channels where you would post. Enterprise buyers in regulated industries rarely discover vendors through founder threads.
Your idea is easy to copy and hard to defend. Publicity can attract competitors faster than customers.
You find it distracting. If writing updates replaces shipping or talking to customers, the habit is costing more than it returns.
You plan to sell soon and the numbers are noisy. Public figures become part of the record a buyer will reconcile. A volatile, poorly labeled history can create questions during diligence. The startup buyer due diligence guide shows what buyers typically check.

There is also a middle ground: share learnings and product progress publicly, and keep revenue private or share it only with investors and prospective acquirers.

Building in public and selling a business

Founders sometimes build in public with an eventual exit in mind. A consistent public record can help buyers discover the business and understand how it grew. On RevenueBug, a founder can mark a startup as for sale and receive private buyer inquiries; for-sale listings must reveal product identity. RevenueBug relays inquiries but does not broker, escrow, or transfer businesses, so the sale itself still needs normal diligence and legal work. The guide to selling a SaaS business covers that process.

Frequently asked questions

What does "build in public" mean?

It means openly sharing the process of building a product or company, such as features shipped, lessons learned, mistakes, and often metrics like revenue or customers, through blogs, newsletters, communities, or social media.

Do I have to share revenue to build in public?

No. Many founders share product progress, customer lessons, and decisions without publishing revenue. Sharing revenue adds credibility when it is clearly labeled and verifiable, but it is a choice, not a requirement.

Is building in public risky?

It can be. The main risks are revealing a copyable strategy, exposing customer or security details, and creating a public record that conflicts with your private data. Decide in advance what you will not share.

How do I make my revenue updates believable?

Use a consistent metric definition, publish on a schedule including bad months, and link to an independent source rather than a screenshot. Provider-verified revenue profiles let readers check the trend for themselves.

Can I build in public anonymously?

Yes. You can share progress under a pseudonym, and RevenueBug's anonymous mode hides product identity while keeping revenue public. Anonymous mode is not available once a startup is marked for sale.

Where should I post build-in-public updates?

Choose the channel where your future customers already spend time, then add founder communities as a secondary audience. One consistent channel usually works better than many sporadic ones.