The weekly build in public update
An example thread for a hypothetical AI code review bot for small teams, annotated post by post.
Goal
Keep followers watching the story and collect product input in public.
When to post it
Every Friday from week two until launch.
Note
Written by us to show the pattern. The product is hypothetical.
The thread, with margin notes
- Week 6 building an AI code reviewer in public. Shipped: inline fixes. Broke: our GitHub app permissions, for 3 hours. Learned: devs ignore any comment longer than 2 lines.
The whole update fits in the first post. Shipped, broke, learned is a format people come back for because it admits failure.
- The 2 line rule changed everything this week. We cut every review comment to one sentence plus a suggested fix. Accepted suggestions went from 1 in 9 to 1 in 4.
One decision, the reason, the result. A number with a before and after is the most reposted shape in build in public.
- What broke: We asked for write access to every repo by default. Two testers uninstalled within an hour. Now it asks per repo. Should have done that from day one.
Owning a mistake in public builds more trust than any feature post. Keep it short and say what changed.
- Next week: the bot learns your team's style guide from past merged PRs. Question for anyone running a small team: Would you rather it enforce your style guide, or just flag drift and let you decide?
Ending on a real question turns readers into participants. Replies to this post are product research and reach at the same time.
Why it works
- Short. Four posts is enough for a weekly update.
- Failure gets as much space as progress.
- One number with a clear before and after.
- A real question at the end, which the founder then answers in replies.
Steal the structure
- Week number + shipped / broke / learned
- The one decision that mattered, with a number
- What went wrong and the fix
- Next week + a real question
Next thread
Thread 03 The how it works technical thread