Build in Public Update Templates for X (Weekly and Monthly)
A build in public update is a regular post sharing what you shipped, your key numbers and what you learned, so followers can watch the product grow. Weekly or monthly updates with the same structure are easiest for you to write and easiest for readers to follow. The templates below give you a repeatable format for good weeks, slow weeks and bad weeks.
When to use this template
- Every week or month on a fixed day, as a routine your audience can expect.
- After a sprint, when you have a few small things shipped and no single big launch.
- When numbers went down and you want to share honestly what happened.
- When you are about to make a decision (pricing, pivot, new feature) and want input.
If the term is new to you, the build in public glossary entry explains the idea.
Templates
The weekly scorecard
The classic format. Same order every week so readers can compare.
[Product] week [number] update:
📈 [Metric 1]: [value] ([change])
💰 [Metric 2]: [value] ([change])
🚢 Shipped: [feature]
🧠Learned: [one lesson]
Next week: [one goal]
The monthly recap
For a monthly rhythm with a bit more reflection.
[Month] at [product]:
• [Revenue or users]: [start] → [end]
• Shipped [number] things, best one: [feature]
• Biggest mistake: [mistake]
• Time spent on [activity]: [hours]
Goal for [next month]: [goal]
The bad-week update
Use this when numbers dipped. Honest bad weeks often earn more support than good ones.
Not a great week for [product].
[Metric] dropped from [old] to [new].
Why: [honest reason]
What I'm changing: [fix]
Building in public means sharing these weeks too.
The decision-in-public update
When you want followers to weigh in on what you build next.
[Product] update: I need to choose.
Option A: [option]
Option B: [option]
[Number] users asked for A. B would [benefit].
Which would you build first, and why?
The small-wins update
For weeks with no big headline, where several small things moved.
Small wins this week on [product]:
✅ [win 1]
✅ [win 2]
✅ [win 3]
No big launch. Just [number] steps forward.
Worked example
Ada builds Tidepool, a booking tool for surf schools. Her week 12 scorecard:
Tidepool week 12 update:
📈 Schools: 41 (+3)
💰 MRR: $1,189 (+$87)
🚢 Shipped: wetsuit size tracking
🧠Learned: schools book on Sunday nights, so that's when I email now
Next week: get the first school in Portugal live
MRR is 41 schools × $29 a month = $1,189. It works because the numbers are small and real, the shipped feature is oddly specific to surf schools, and the lesson is a timing insight other founders can steal.
Tips
- Pick 2 or 3 metrics and keep them every week. Changing metrics looks like you are hiding a bad one.
- Post on the same day each week. Readers start to look for it.
- Put the change in brackets next to each number so the trend is visible at a glance.
- Include one thing that went wrong. Updates that are all wins read like adverts.
- Add a screenshot of the feature you shipped. It turns a list of numbers into something people can see.
- Reply to every comment on the update. Your regulars become your first fans.
Frequently asked questions
How often should I post build in public updates?
Weekly suits early products where small changes matter. Monthly suits products with steadier numbers or busier founders.
What metrics should I share?
Revenue (MRR), customers or active users and one activity metric such as signups or churn. Share what you are comfortable with and stay consistent.
What if my numbers are tiny?
Share them anyway. Small numbers attract people at the same stage, and watching them grow is the whole appeal.
Should my update be a thread?
A single post works for weekly updates. For a monthly recap with more detail, open with the scorecard and add a short thread beneath it.
Write this week's update faster
List your numbers and what you shipped, then let the free post generator shape them into an update you can edit. For a monthly lessons post, see the lessons learned templates.