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:
- The cadence. Weekly is sustainable for most people. Daily is not.
- The format. The same structure every time makes updates easy to write and easy to read.
- 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.
Status, verified revenue and stats. Free for up to 5 projects.
Keep reading
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 readHow 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 readDoes 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.