TL;DR: To automate build in public updates, don’t auto-post every commit. Collect a week of commits, closed issues and your own notes, pick the one or two things worth telling, and let an AI agent draft a different version for X, LinkedIn and r/SideProject. You approve, it schedules. The choosing stays with you; the reformatting and queueing don’t have to.
It’s Sunday night. You shipped a billing fix, a CSV export and a long-overdue dark mode this week, and you promised yourself you’d “build in public.” You open X, type “This week:” and stare at it. Forty minutes later you have one tweet, no LinkedIn post, and a vague guilt about Reddit. By Wednesday you’ve skipped the habit again.
The work isn’t the problem. The weekly translation from “what I did” to “what’s worth saying, on three different networks” is. This guide is for solo founders and indie developers who already ship regularly and want the posting to take ten minutes instead of an evening.
Why most build in public streaks die
Most advice treats consistency as willpower. I’d treat it as a pipeline problem. Three things kill the habit:
- Nothing to say on the day. You write posts when you feel like it, which is when you’ve had a good week. Bad weeks, which are the interesting ones, go unposted.
- Three networks, three formats. A thread on X, a story on LinkedIn, a descriptive post on Reddit. Writing from scratch each time triples the cost.
- Posting competes with building. Write-ups published late at night get skipped first.
Guides on the topic say much the same thing: pick a rhythm based on the natural unit of your work, such as a weekly note or a changelog after each release, instead of posting daily just to post. buildinpublic.guide is one of several that make the point. A daily cadence tends to produce filler.
What to share (and what to leave out)
Not everything you did is a post. A useful filter for each candidate item:
| Candidate | Post it? | Why |
|---|---|---|
| A feature shipped | Yes, with the reason | “Added CSV export because 4 users asked” beats “Added CSV export” |
| A bug that bit users | Yes | Mistakes get replies; polished changelogs don’t |
| A metric (signups, MRR) | Optional | Revenue sharing is a choice, not a requirement |
| A refactor | Rarely | Unless you learned something transferable |
| An unfinished idea | Sometimes | Good for a question post |
Sharing revenue in particular is optional. Some founders find it builds trust; others find it attracts comparison and the wrong audience. You can build in public around signups, user feedback or technical decisions and skip money entirely.
How to build a weekly update from your commits
This is the part worth automating. Here is the routine I’d use, in the order the work happens.
- Pull the raw material. On Friday, export the week:
git log --since="7 days ago" --oneline, the issues you closed, and any note files or screenshots. That’s the input, not the post. - Mark the one or two items worth telling. Give each a reason: who asked, what broke, what surprised you. Models can’t know which change made you wince; you can.
- Have the agent draft per network. Same facts, different shape (next section).
- Edit for voice. Cut anything that reads like a press release. If it doesn’t sound like you typing in a hurry, it’s not done.
- Schedule across the week, not all at once on Sunday. The X post goes out Monday morning, LinkedIn on Tuesday, Reddit midweek.
A throwaway weekly.md in the repo works well as step 2’s home: three bullets with a reason each. That file is what you hand the agent.
One update, three different posts
The same “CSV export shipped” update should not be pasted three times.
- X: Short and specific. The hook is the user request. “Four people emailed asking for CSV export. Shipped it Thursday. Took 2 hours because I’d already built the table component.” A screenshot helps. If there’s a longer story, put it in a reply thread.
- LinkedIn: The same event with the decision behind it. Why export mattered to the kind of customer you’re trying to reach, what you chose not to build. Our guide to scheduling LinkedIn posts covers timing and first-comment mechanics.
- Reddit (r/SideProject): A proper project post: what it is, who it’s for, what you learned. Unlike most subreddits, r/SideProject exists for showing your own work, but low-effort “check out my app” posts, affiliate links and repeated reposts still get removed. Post only when there’s a real milestone, not every week, and answer the comments you get.
The Reddit trap
Weekly updates fit X and LinkedIn. They don’t fit Reddit. The same source notes that each post should bring something new, such as a launch, a major update or a lesson learned, and that the community runs on reciprocity: give real feedback on other people’s projects too. If your pipeline posts to Reddit every Friday, you’ll look like a spammer and probably get filtered. I’d queue Reddit posts manually, or let the agent draft them for you to send when there’s something real. For the longer story on the Reddit side, see automating Reddit posting.
Where an AI agent fits
Be honest about what a model does well here. It’s good at turning a three-bullet note into three differently shaped drafts, trimming to a character limit, and queueing. It’s bad at knowing what was interesting. Left alone, it writes the generic “Excited to share…” post, which is the one failure mode build-in-public writers call out most: if your posts read like ChatGPT wrote them, the authenticity is gone.
PublishPort handles the posting half. You sign in to your own accounts once in the desktop client; your AI agent calls list_capabilities and local_bash through the relay, reads each command’s --help, and posts from your logged-in sessions. Hand it weekly.md and it can return drafts for X and LinkedIn and queue the ones you approve. Plans are on the pricing page. If you’re comparing this with a no-code route, n8n vs an AI agent for social posting lays out the trade-off, and announcing a GitHub release covers the per-release version of this same idea.
Limits to know:
- The desktop client has to be running and logged in when a post is due.
- Text posts are the dependable path. Images vary by network, so check them in a dry run first.
- Models invent details. Check every number in a draft against your notes.
- Run one throwaway post before you trust the pipeline; testing an agent before it posts has the routine.
A weekly build in public checklist
- Friday export: commits, closed issues, one screenshot
weekly.mdwith one or two items and a reason each- Separate drafts for X, LinkedIn, and Reddit only if there’s a real milestone
- Numbers checked against your notes
- Posts spread over the week
- Ten minutes blocked for replies
FAQ
How often should I post build in public updates?
Weekly or per release is enough for most solo builders. Daily posting can work, but it tends to produce filler and pulls time from the product.
Do I have to share revenue when building in public?
No. Revenue is one optional layer. Many founders share signups, user feedback or technical decisions instead.
Can I auto-post my git commits to X?
You can, and I wouldn’t. Commit messages are written for you, not for strangers. Use them as raw material and post the one or two changes that have a story.
Is it okay to post build in public updates on r/SideProject?
Yes, that’s what the community is for, provided it’s your own project, properly described, and you engage with other makers. Don’t repost the same project without something new.
Can AI write my build in public posts?
It can draft them well from your notes. Without your notes it writes generic announcements, so keep the editing pass.
What if I have nothing to share this week?
Post a short note about what’s stuck or what you’re deciding. Honest “I didn’t ship” posts often get more replies than a polished changelog.