How to Write a Build in Public Update People Read
How to write a build in public update with a repeatable format: what happened, what you learned, what is next, and a number. Examples and a template you can reuse weekly.
A build in public update people actually read follows one format: what happened, what you learned, what is next, and a number if you have one. Keep it specific and honest. The repeatable structure is what lets you post weekly without staring at a blank screen.
Build in public sounds simple until you sit down to write the update and realize you have no idea what to say. So you write "made some progress this week, exciting things coming" and wonder why nobody replies. The fix is not more discipline. It is a format, so every update writes itself. Here is the one I use.
How do you write a build in public update?#
Follow four beats: what happened, what you learned, what is next, and a number if you have one. That is the whole skeleton. Once you have it, an update stops being a blank-page problem and becomes a fill-in-the-blanks one, which is the only way to keep posting them for months.
The reason vague updates fail is that they give the reader nothing to hold. "Made progress" is not progress they can see. "Cut signup from four steps to one and conversion went from 9 percent to 14 percent" is. Specifics are what make people care about a stranger's project.
There is a second reason the format matters, and it is about you, not the reader. Friction is what kills consistency. The week you are buried in support tickets is the week a blank-page update gets skipped, and one skip becomes a habit. A template you can fill in five minutes survives the busy weeks. That is the difference between a build-in-public account that runs for a year and one that goes quiet after a month.
What is the repeatable format?#
The four beats above, in roughly that order, kept short. You do not need all four every time, but the more you hit, the more the update feels like a story instead of a status line. Here is the structure spelled out:
- What happened: one concrete thing you shipped, fixed, or decided this week.
- What you learned: the lesson, especially if it surprised you or cost you.
- What is next: the one thing you are doing next, so people can follow along.
- A number: signups, revenue, users, a churn rate, anything real.
I keep these four as a saved template and just refill them every Friday. Treating it as a form, not an essay, is what took my updates from "sometimes, when I feel inspired" to "every week without fail".
Why does a number matter so much?#
Because a real metric turns a claim into evidence, and evidence is what makes people trust and root for you. "Growing nicely" is noise. "Went from 40 to 110 paying users this month" is a story with stakes. Numbers also create a streak people want to keep watching, which is half of why build in public works at all.
You do not need a flattering number. The honest ones travel furthest. "Lost two customers this week, here is what I think went wrong" gets more genuine engagement than any "up and to the right" post, because it is rare and real. If you have no metric this week, do not fake one. Share a decision or a screenshot instead.
One more thing about numbers: pick the same metric and report it every week. If you bounce between signups one week and revenue the next and visitors the week after, people cannot follow the trend. A single number tracked over time becomes a tiny ongoing story, and stories are what make strangers come back to read the next update.
What does a good update look like versus a bad one?#
The good one is specific, honest, and has a clear shape. The bad one is vague, polished, and about feelings instead of facts. Put them side by side and the difference is obvious.
| Element | Weak update | Strong update |
|---|---|---|
| What happened | "Made good progress this week!" | "Rebuilt onboarding from 4 screens down to 1." |
| What you learned | (missing) | "Half the dropoff was on screen 2, a field nobody needed." |
| What is next | "More exciting stuff soon." | "Next: testing whether a demo video lifts trial starts." |
| Number | "Lots of new users." | "Trial starts up 31 percent week over week, 140 total." |
| Tone | Hyped, vague | Honest, specific |
Read the right column and you can picture the founder's week. Read the left and you learn nothing. People follow builds where they can see the actual moving parts.
How often should you post these?#
Weekly is the rhythm I would point most founders to. It is frequent enough that the story keeps moving and slow enough that each update has something real to say. Daily updates only work if you genuinely make daily progress worth sharing, otherwise you end up padding, and padding is how build in public turns into noise.
If staring down a weekly deadline feels heavy, it gets much lighter when you batch. Jot notes as the week happens, then write and queue the update in one short session. That is the same habit behind scheduling social posts as a solo founder, and it is what keeps the streak alive on the weeks you are slammed.
What if you have nothing impressive to share?#
Share the messy middle, because the messy middle is the most relatable part of any build. A bug that humbled you, a feature you killed, a customer conversation that changed your mind. These often outperform the wins, since they prove you are a real person making real calls. I wrote a whole piece on this for the early days in build in public when you have nothing to show, and it is worth weighing the tradeoffs in the pros and cons of building in public before you commit to it long term.
Where to start#
Save the four-beat template somewhere you will see it. This Friday, fill it in with one concrete thing that happened, one lesson, your next step, and one real number, then schedule it. Do that for four weeks and you will have a habit instead of a chore.
Frequently asked questions
How do I write a build in public update?
Follow a simple format: what happened this week, what you learned, what is next, and a number if you have one. Keep it specific and honest. The structure means you never stare at a blank screen.
What should a build in public update include?
A concrete thing that happened, a lesson from it, your next step, and ideally one real metric like signups, revenue, or users. Skip vague feelings and round numbers you made up.
How often should I post build in public updates?
Weekly is a sustainable rhythm for most founders. It is frequent enough to show progress and slow enough that each update has something real in it. Daily works only if you genuinely have daily progress.
Do I need numbers to build in public?
No, but one real number makes an update far more credible and interesting. If you have no metric this week, share a decision, a screenshot, or a lesson instead. Never invent a number.
Write once. Post everywhere. Never miss a day.
posthell takes your post, tailors it per network, and publishes on schedule to X, LinkedIn, Threads and Bluesky. Honest founder pricing from $12 a month, no agency bloat.