Build-in-Public Autopilot

Automate Your Build-in-Public Tweets: GitHub Merges to X, on Autopilot

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, and every merge becomes a tweet in your voice, secrets scrubbed, scheduled at your best time. Approve every draft, or run full auto.

Start your 14-day trial See how it works

Part of TimeToPost Pro · $49.99/mo · Last updated June 2026

build-in-public autopilot

$ git merge feat/thread-support

● Webhook received · scrubbing diff for secrets…

↳ clean — no credentials in the change

● Drafting tweet in your voice…

Threads finally work in TimeToPost. Write the whole thing, schedule it once, and each part publishes as a chained reply at your best time. Built it because a customer couldn’t ship their 7-part launch thread. Now they can.

✓ Under daily cap (1/3) · scheduled for Tue 9:40 AM — your engagement peak

Waiting for your approval.

How it works

Five steps, none of which you have to remember. Doing nothing produces a draft — you only spend effort to stop a post or polish one.

01
You merge
A webhook fires the moment you merge a pull request or push to your main branch. No CI config, no new dependency — just a webhook in your repo settings.
02
An LLM drafts the tweet
It reads what actually shipped — the PR title, description, and change summary — and writes a tweet in your voice that leads with the user-facing outcome. Not a changelog line.
03
The daily cap protects your feed
You set a hard cap of 1 to 3 posts a day. Ship nine PRs and your audience still sees only the one or two that matter. The rest wait or get dropped.
04
It schedules at your optimal time
A 2 a.m. merge becomes a 9:40 a.m. tweet — whenever your audience actually shows up, based on your own engagement history, not a generic best-times chart.
05
You approve — or you don’t
In approval-queue mode, every draft waits for your tap. In full-auto mode, it posts straight to your queue. Start cautious, flip to auto when you trust it.

Why it won’t turn your account into a changelog bot

You’ve seen the failure mode: an account that tweets “v2.4.1 released! Bug fixes and performance improvements” eleven times a week. Nobody follows it. Three mechanisms make sure Autopilot never becomes that.

A hard daily cap, not a target

The single most important spam-prevention feature. An account that narrates every commit stops being a person. Your cap is a ceiling — productive days for you never become spammy days for your followers.

Approval mode by default

Until you trust the drafts, nothing posts without you. The push turns "write a build-in-public tweet" into "read 240 characters and tap a button." Most people start here; some stay forever, and that’s a perfectly good way to run it.

Secrets are scrubbed before any model sees them

Every diff is checked for anything shaped like a credential — tokens, keys, connection strings, env var names, internal hostnames — before the LLM is ever asked to write. The only thing worse than no launch tweet is one with your env file in it.

Frequently asked questions

Can AI write my build-in-public tweets?

Yes. Build-in-Public Autopilot uses an LLM that reads what you just shipped — the PR title, description, and a change summary — and drafts a tweet in your voice that leads with the user benefit rather than the commit message. It is not a template like "Released: " + pr.title; a dependency bump and a flagship feature produce very different tweets, and genuinely boring changes are skipped entirely. You can keep approval mode on so you read and approve (or edit) every draft before it goes out.

How do I auto-tweet GitHub commits?

Add a webhook to your repository (Settings → Webhooks), point it at the URL TimeToPost gives you, set the content type to application/json, paste in the signing secret, and subscribe to Pushes and Pull requests. From then on, every merge to your main branch triggers a drafted tweet. You choose whether each draft waits in an approval queue or posts automatically. There is nothing to install in your codebase and no GitHub Action to maintain.

Won’t this spam my followers like a changelog bot?

No, and that is the failure mode the feature is designed around. Three mechanisms prevent it: a hard daily cap you control (1 to 3 is the sweet spot), so a busy build day never floods your feed; an LLM that writes like a human and skips boring chores instead of announcing them; and approval-queue mode, which holds every draft for your review by default. Volume repels; consistency compounds — Autopilot optimizes for the second.

Is it safe with my secrets?

Every diff is scrubbed for anything resembling a secret — API keys, tokens, passwords, connection strings, environment variable names, internal hostnames, IP addresses, and private URLs — before any of it reaches the language model. Drafts are generated from your PR title, description, and a change summary, not from a dump of your source. The inbound GitHub webhook is verified with a timing-safe HMAC signature so only your repo can post events. In approval-queue mode, nothing publishes until you have read it.

Does it post the instant I merge?

No — that is the point of pairing it with a scheduler. Drafts are queued for your optimal posting time, computed from your own engagement history, so a late-night merge lands when your audience is actually awake. If something is genuinely time-sensitive, you can publish a queued draft immediately from your dashboard.