The Build-in-Public Content Workflow: From Commits to Posts on Autopilot

Building in public starts with a simple problem: the work happens, then the moment to talk about it passes. You ship something on Tuesday, get pulled into a bug on Wednesday, and by Friday the useful detail is gone. A small capture and review loop keeps that from happening.

This workflow starts with your actual work and ends with a scheduled X post. It does not ask you to invent a separate content project.

Show the work, not only the announcement

Announcements are one option: a launch thread, a milestone screenshot, or a note about a new feature. A useful alternative is to show what the work looked like. Share the failed attempt before the fix, the unexpected API cost, or the decision behind a tradeoff.

The point is clarity. A concrete account of the work gives readers something they can understand and respond to. If you are building in public, include the work behind the result.

What to share: commits, costs, prompts, numbers

You don't need a content strategy meeting to figure out what to post. You need a list of things that are already true about your week, and a habit of noticing them.

• Commits and PRs. Not every one, but the ones that changed something a user would notice, or that took longer than expected and taught you something.
• Costs. What you're paying for infrastructure, an API, or a tool, and what changed after you paid for it. Use a real number when you are ready to share one.
• Prompts and workflows. If you used an AI agent to plan a migration or draft a feature, the prompt itself is often more interesting content than the feature.
• Numbers that move. Signups, MRR, churn, a support ticket volume that dropped. Directional is fine, you don't need to bare your entire P&L.
• Decisions and the reasoning behind them. Why you picked one approach over another. This is the content type most founders skip and it's usually the one with the best replies.

None of this requires you to sit down and "write content." It requires you to keep a running note of what happened, which is the next section.

Pick a cadence you can review

Founders tend to overcorrect in one of two directions: they post nothing for a month, then dump five updates in two days when guilt kicks in, or they try to post daily and burn out within three weeks. Neither holds up.

A practical starting point is two or three posts a week. That gives you room to review each draft and keeps the workflow connected to real shipping instead of forcing a post every day. Change the cadence if your work produces fewer useful updates.

The cadence is a constraint, not a promise of performance. Keep the schedule only if it helps you share useful work without manufacturing updates.

The pipeline: work, note, draft, queue

Here's the actual mechanics, in four steps.

1. Work. You do the thing you were going to do anyway: ship a feature, fix a bug, close a deal, hit a number.

2. Note. The moment something notable happens, you write one line about it somewhere durable. A running doc, a Slack channel to yourself, a changelog file in the repo. The bar is low: "fixed the token refresh bug that was silently killing IG posts after 60 days" is a complete note. This step is the one people skip, and it's the one that makes everything downstream possible. If you don't capture the moment, you can't turn it into a post three days later, you'll have forgotten the details that made it interesting.

3. Draft. Once or twice a week, turn your notes into actual post drafts. This is where an AI agent earns its keep, more on that below, but even doing it manually from a running note is faster than starting from a blank page.

4. Queue. Schedule the drafts across the week rather than posting them all at once. This is the part that turns "I have three updates" into "I look active every other day."

Keeping cadence during heads-down weeks

The weeks that kill a build-in-public habit are the quiet ones: deep in a refactor, no visible launches, nothing that feels post-worthy. This is exactly when a recurring queue matters most.

The fix is to build slack into the system before you need it. Keep a small backlog of evergreen posts, things like a lesson from an earlier failure, a tool you rely on, a number you haven't shared yet, and let those fill the gaps automatically when your notes file is thin. A recurring queue means the posting schedule doesn't depend on that particular week being eventful. You're not performing progress you didn't make, you're just pulling forward something true that you haven't posted yet.

The other lever is batching drafts ahead of a week you know will be heads-down. If you know a big migration is eating your next five days, spend twenty minutes before it starts turning your recent notes into three or four drafts and schedule them across the week. Future-you, buried in the migration, doesn't have to think about posting at all.

Where AI agents fit: draft from your changelog, you approve

This is the part that actually removes the friction instead of just organizing it. If your coding agent is already the one writing the commit messages and PR descriptions, it's a short step to have it draft the announcement too, using the same context it already has about what changed and why.

TimeToPost's MCP server (https://api.timetopost.co/mcp) exposes drafting and scheduling tools directly to an agent. A coding agent that just merged a PR can draft a post about it as part of finishing the task, the same way it might update a changelog.

The approval gate matters. Letting an agent draft from your commit history is different from letting it publish unreviewed. TimeToPost's approval queue keeps a human step between draft and publish: the agent proposes the post, you approve or edit it, and only then does it go out. The MCP setup guide covers the connection and available tools.

For the specific GitHub-to-post product workflow, see Build-in-Public Autopilot.

Why the system matters more than the content

None of this is about becoming a better writer. It's about removing the two failure points that kill most build-in-public habits: forgetting the moment before you can write about it, and letting a busy week turn into a dead week on the timeline. A note-taking habit solves the first problem. A recurring queue solves the second. Everything else, drafting help from an agent, scheduling at good times, an approval gate you trust, is just removing friction from a system that already works once those two pieces are in place.

If you're trying to build a habit around fewer daily decisions in general, eliminating decision fatigue from your posting system is a useful companion to this one. The same principle applies: decide the system once, then let it run.

FAQ

How much time does this actually take per week? The time depends on how many notes you collect and how much editing each draft needs. Start with one review session after you have shipped something, then keep the workflow only if it saves time.

Do I need to post every single day to build in public effectively? No. Daily posting is optional. Two or three reviewed posts a week is a reasonable starting point, then you can adjust it to the amount of work you have to share.

What if I genuinely don't have anything to share this week? This is what the recurring queue is for. Keep a small backlog of evergreen posts, a past lesson, a tool you use, a number you haven't shared yet, so a quiet week doesn't mean an empty timeline.

Should the agent be allowed to publish without me reviewing it first? For most founders, no. Draft automatically, but keep a human approval step before anything publishes. It costs you a few minutes and it means you never wake up to a post you didn't actually want to send.

What should I never share, even in the name of transparency? Anything that exposes a customer's private data, anything that reveals a security vulnerability before it's patched, and specific numbers you're not actually ready to be held to publicly. Process transparency doesn't require zero discretion.