Building in Public: Sharing Revenue and Failures

Building in public means sharing your work as you go: what you are making, how it is doing and what went wrong. It can bring early users, useful feedback and friends who are on the same path. It can also feel like performing, attract copycats and eat time you should spend on the product. This guide is about doing it in a way that is honest and sustainable, with a focus on the two hardest parts: revenue and failure.

Decide what you are building in public for

Before you post anything, pick a reason. Common ones:

• Accountability. Saying "I will ship X by Friday" in public makes it more likely you will.
• Distribution. People who watched you build are more likely to try the thing.
• Learning. Posting a problem often gets you an answer from someone who solved it.
• Community. Solo work is lonely. Other builders help.

Your reason shapes what you share. If it is accountability, share goals and deadlines. If it is distribution, share progress and demos. Revenue matters most when trust is the goal.

Sharing revenue

Pick a number and a definition

Choose one metric and stick to it. For subscription products that is usually MRR. For one-off sales or stores it is revenue over the last 30 days, net of refunds. Say which one you are using. Switching metrics every month (MRR one month, "total sales" the next) looks like you are picking the best-looking figure, even if you are not.

Make it verifiable

Faked revenue screenshots have been called out publicly in maker circles, and readers know it happens. A number pulled directly from Stripe or Shopify and refreshed automatically is much harder to doubt. We wrote a step-by-step guide to doing that safely with a read-only key: how to show verified MRR.

Share the boring months too

A revenue chart that only appears when it goes up is marketing, not building in public. The flat months and the dips are where other founders learn the most, and where you look most credible.

Know when to stop

Some founders share openly while small and go quieter as revenue grows, usually because competitors start paying attention or because posting numbers starts to feel like bragging. That is a reasonable choice. You can keep sharing status and lessons without the number. Building in public is not a contract.

Sharing failures

Failure posts are the most useful thing in the build-in-public world, and the rarest. A good one answers four questions:

1. What did you try? One paragraph, no spin.
2. What happened? Numbers if you have them: signups, revenue, churn.
3. Why do you think it failed? Your best guess, labelled as a guess.
4. What are you doing differently now?

Keep it short. You are not writing a post-mortem for a board. You are leaving a note for the next person.

List discontinued projects, honestly

Most makers quietly delete dead projects from their bio. It is tempting, but it throws away evidence. A list that shows three discontinued projects, one acquired and one active tells a better story than a single active project with no history. It says: this person ships, learns and keeps going.

If you keep a project list, give every project a status:

• Active or Building for current work
• On hold for paused projects you might come back to
• Acquired for anything you sold
• Discontinued for things you shut down

Add a one-line note on why a project ended if you are comfortable with it. "Shut down: users loved it, nobody paid" is more useful to readers than silence.

A simple weekly routine

Building in public works best as a habit, not a burst. Something like:

• Monday: one post on what you plan to ship this week.
• During the week: share one small thing you learned or one screenshot of progress.
• Friday: what shipped, what did not, and why.
• Monthly: revenue (if you share it), traffic and one lesson.

Thirty minutes a week is plenty. If it takes longer, cut back.

Handling doubt and awkward questions

Share numbers in public long enough and someone will question them. A few ways to handle it calmly:

• Show the method. "Last 30 days of Stripe charges, net of refunds" answers most doubts on its own.
• Point to the source. A verified number linked to its payment provider settles more than an argument does.
• Answer once, then move on. You do not owe every reply a thread.

You will also get questions you do not want to answer, like exact churn or who your biggest customer is. "I do not share that one" is a complete answer. Building in public means sharing what you choose to share, not everything.

Things to avoid

• Vanity metrics with no context. "10k impressions!" means little on its own.
• Only sharing wins. People notice.
• Oversharing customer data. Never post customer names, emails or private messages without permission.
• Letting the audience steer the product. Likes are not demand. Paying users are.

A home base for all of it

Posts scroll away. It helps to have one page that holds the current state: what you are building, what you shipped, what you shut down and, if you share it, what it earns. That way a new follower can catch up in one click instead of scrolling back a year.

That is what makerhandle is for. Each project gets a status (including Discontinued and Acquired), optional verified revenue from Stripe or Shopify, and a place on the public leaderboard if you want it. See makerhandle for building in public, or claim your handle.