How to Build in Public: A Practical Start

By Dane Dolph · · 2 min read · #Building in public #Guides

"Build in public" sounds simple: share what you are working on. In practice most people start with enthusiasm, post for three weeks and go quiet. Here is a setup that lasts. For the definition, see what building in public means.

Decide what you will share

Before your first post, decide three things:

  1. The cadence. Weekly is sustainable for most people. Daily is not.
  2. The format. The same structure every time makes updates easy to write and easy to read.
  3. The numbers. Pick one or two you will report every time, even when they are bad.

A good default update has four parts: what shipped, one lesson, one number, what is next. It takes ten minutes to write.

Pick numbers you can keep sharing

The most common mistake is sharing numbers only when they are good. Readers notice the silence. Pick metrics you are willing to show in a bad month:

  • Revenue: MRR for subscriptions, or the last 30 days of sales for everything else
  • Users: signups, active users or customers
  • Traffic: visitors to your site or page

If revenue feels too personal, start with users. You can add revenue later. See MRR vs last 30 days: which to show.

Make the numbers checkable

Screenshots are easy to fake and go stale the moment you post them. A link to a live, verified number is better:

  • connect Stripe or Shopify to a page that shows verified revenue with read-only access
  • turn on a public stats page for traffic
  • keep both on one link that you add to every update

On makerhandle, verified revenue and an optional public stats page live on the same page as your projects. Read how to run an open startup page.

Choose where to post

Go where your likely users already are, not where builders are:

  • X and Bluesky for developer and indie audiences
  • LinkedIn for B2B products
  • Indie Hackers and relevant subreddits for longer write-ups (read each community's self-promotion rules)
  • A newsletter for the people who want every update

Post the same update everywhere, adapted slightly, and point every post to one link. Tag those links with UTM parameters so you can see which platform sends people. See UTM tracking for your link in bio.

Share the failures too

The posts that build the most trust are often the ones about things that did not work: a launch that flopped, a feature nobody used, a project you shut down. Give dead projects an honest status like Discontinued rather than deleting them. Your track record is more interesting with them. Read building in public: sharing revenue and failures.

Protect your energy

  • Write updates in batches if you need to.
  • Skip a week rather than forcing a post. Say so next time.
  • Do not reply to every comment.
  • Keep anything that would help a direct competitor more than your users to yourself.

A two-minute setup

Make one page with your projects, their status and their numbers, put it in every bio, and link it from every update. makerhandle is free for five projects and built for exactly this. See makerhandle for building in public.

Put all your projects on one page

Status, verified revenue and stats. Free for up to 5 projects.

Claim your handle

Keep reading

Oct 19, 2026 · 3 min read

Tap Bio Is Shutting Down: What to Do Now

Tap Bio has reportedly set October 31, 2026 as its closing date, with pages deleted after. A short checklist to save your content and move your link.

Oct 18, 2026 · 4 min read

How to Show Shopify Store Revenue Without Admin Access

Show real Shopify revenue publicly without handing out your admin login. Dev Dashboard apps, read_orders and the 2026 custom app change explained.

Oct 17, 2026 · 3 min read

Does Your Link in Bio Need a Cookie Banner?

Link in bio tools, cookies, pixels and GDPR in plain English: what triggers a consent banner, what does not, and how to keep your page simple.