Your Repo Can Tweet Now: Build-in-Public on Autopilot
Everyone agrees building in public works. Sharing your progress compounds: each small update earns a little trust, a few followers, an occasional customer — and the people who show up for update forty were often hooked by update four. The founders you think of as "great at Twitter" are mostly just founders who kept going.
And that's exactly where it falls apart. The pattern is almost universal: a founder commits to building in public, posts daily for two weeks, and then ships a hard feature — and the streak dies. Not because they stopped building. Because they were too busy building to say so. The cruel irony of build-in-public is that the more you have to talk about, the less energy you have to talk about it.
The friction isn't writing one tweet. It's the context switch: you've just merged a branch you fought with for two days, your head is full of edge cases and migration scripts, and now you're supposed to put on your marketing brain, summon a hook, and remember what time your audience is awake. So you tell yourself you'll post tomorrow. Tomorrow you're debugging something else.
We built a feature that removes that switch entirely.
Introducing Build-in-Public Autopilot
Build-in-Public Autopilot connects your GitHub repository to TimeToPost. When you merge a pull request or push to your main branch, it:
- Reads what actually shipped — the PR title, description, and a summary of the change.
- Drafts a tweet in your voice — an LLM turns the change into something a human would actually want to read, not a changelog line.
- Schedules it at your optimal time — using the same best-time engine that powers the rest of TimeToPost, built from your own engagement history rather than a generic chart.
- Asks you first — or doesn't. In approval-queue mode (the default), you get a push notification, glance at the draft on your phone, and tap approve or edit. In full-auto mode, the tweet goes into your queue without you lifting a finger.
Merge code, get an audience. The work you were already doing becomes the content you were never getting around to making.
The obvious objection (and why we built around it)
Let's name the failure mode, because you've seen it: the changelog bot. An account that tweets "🚀 v2.4.1 released! Bug fixes and performance improvements" eleven times a week. Nobody follows it. Nobody should. Automated posting has a deserved reputation for producing exactly this, and if Autopilot turned your account into that, it would be worse than posting nothing — it would burn the audience you're trying to build.
So the feature is designed, first and foremost, not to be a changelog bot. Three mechanisms do the work:
An LLM with your voice, not a template. The draft isn't "Released: " + pr.title. The model reads what the change actually does and writes the way you write — what problem it solves, why it was annoying, what's now possible. A dependency bump and a flagship feature should not, and do not, produce the same kind of tweet. Boring changes (chores, version bumps, typo fixes) can simply be skipped: not everything that merges deserves airtime, and Autopilot knows the difference.
A hard daily cap. You set a maximum number of Autopilot posts per day, and it is a cap, not a target. Shipped nine PRs today? Your audience still sees the one or two that matter, picked from the queue — the rest wait or get dropped. The cap is the single most important spam-prevention feature, because the failure mode of every automated posting tool is volume. Consistency compounds; volume repels.
Approval mode by default. Until you trust the drafts, every tweet waits in a queue. The push notification turns "write a build-in-public tweet" — a ten-minute context switch — into "read 240 characters and tap a button" — a five-second glance. Most people start here. Some stay here forever, and that's a perfectly good way to run it: the point was never zero human involvement, it was zero friction.
What a draft actually looks like
Concrete example. Last night we merged this into TimeToPost itself:
feat(posts): X thread support — chained replies end to end [TIM-64]
The PR description explains that schedule_post previously only created standalone tweets, and now accepts a thread array that gets published as chained replies. Here's the kind of draft Autopilot produces from that:
Threads finally work in TimeToPost 🧵
Until today you could schedule a tweet — but not a thread. Now you write the whole thing, schedule it once, and we publish each part as a chained reply at your best time.
Built it because a customer couldn't ship their 7-part launch thread. Now they can.
Notice what it's doing: it leads with the user-facing outcome, admits the previous limitation, and ends with the reason the work happened at all. That's a build-in-public tweet, not a release note. And if you'd rather it said something else — that's what the edit button in the approval queue is for.
Threads for the big stuff
Some releases don't fit in 280 characters, and flattening a major launch into one tweet wastes it. When a merge looks like a big release — a release tag, a large PR, a milestone you've marked — Autopilot can draft a thread instead: an anchor tweet plus chained replies walking through what shipped and why it matters. (This rides on the X thread support we shipped this week — the same thread capability available in the API and MCP server.)
Day-to-day merges get a single tweet. Launch days get the full thread treatment. The shape of the content follows the shape of the work.
Why this beats discipline
You could do all of this manually. Plenty of founders try. But "I'll remember to tweet after I merge" is a system with a single point of failure: your willpower at the exact moment it's most depleted. The merge is when you're done thinking about the feature — asking yourself to immediately start marketing it is asking for the context switch your brain most wants to avoid.
Autopilot inverts the default. Doing nothing now produces a draft; you only spend effort to stop a post, or polish one. The activation energy flips sign — and consistency, the thing that actually compounds in build-in-public, stops depending on your busiest-day discipline. Your repo already contains the story of what you're building, told one merge at a time. This just reads it out loud.
One more thing
When this blog post merged, the PR that shipped it triggered Build-in-Public Autopilot, which drafted the launch tweet announcing this post, scheduled it for our optimal slot, and pinged a phone for a one-tap approval. The announcement that brought you here was, quite possibly, written by the feature it announces.
That's the loop: ship the thing, and the thing tells people you shipped it.
FAQ
Will it leak private code or secrets?
The drafts are generated from the PR title, description, and a change summary — not from a dump of your source. You control which repos are connected, and in approval-queue mode nothing is posted until you've read it. If you work in a sensitive codebase, keep approval mode on and connect only the repos whose existence is public anyway.
What if a draft is just… bad?
Then you edit it or kill it — that's a tap from the push notification. Bad drafts cost you five seconds in approval mode, and every edit is a signal about the voice you actually want. If you find yourself rejecting most drafts, stay in approval mode; full-auto is an earned setting, not a default one.
How many tweets will this send per day?
At most your daily cap, which you set — and many days fewer, since routine merges (dependency bumps, chores, small fixes) don't generate drafts at all. The cap exists precisely so that a productive day for you doesn't become a spammy day for your followers.
Does it post the second I merge?
No — that's the point of pairing it with a scheduler. Drafts are queued for your optimal posting time based on your own engagement history, so a 2 a.m. merge becomes a 9:40 a.m. tweet, or whenever your audience actually shows up. If something is genuinely time-sensitive, you can always publish a queued draft immediately.
Build-in-public was never a content problem — you produce the raw material every time you merge. It was a friction problem. Connect a repo, set a cap, keep your thumb on the approve button, and let the streak survive your busiest weeks.
See how TimeToPost can help you implement these strategies.