Not thirteen networks. Five, and a filter that knows what to skip.

The short answer

One of us went wide

BuildCast went wide on both axes. More GitHub events in, more platforms out. Commits, PRs, issues and releases become captions that reach thirteen places, two of them native and the rest over OAuth. If your problem is presence in a lot of rooms, that is the right shape and I do not have it.

I went narrow on both. One event in, merged PRs only. Five networks out, X, Bluesky, Mastodon, LinkedIn and Discord, plus a changelog feed in Atom and JSON. No Instagram, no TikTok, no Facebook, no Pinterest, and there is not going to be. The people I built this for are not launching developer tools on Pinterest. The five, and what each gets.

Narrowing buys depth in two places most tools leave shallow. Deciding what not to post, and deciding who is speaking. The rest of this page is about whether that is the trade you want.

Why the category matters

Automate the trigger and the game is restraint

Both of us answer the same complaint, and BuildCast states it as well as anyone. Developers build things, nobody knows about it. The calendar is empty because nobody triggered anything, not because writing is hard.

Automate the trigger and the whole game becomes restraint. Post on every commit and you train people to scroll past you. Both products know this. BuildCast’s answer is smart signal scoring, one judgment separating meaningful updates from noise. Mine is a ladder of named rules, run before a draft exists: bot authors, lockfile churn, paths marked publish: never, a marketing:skip label, diffs under ten meaningful lines. Small survivors are held and flushed as a weekly roundup instead of going out alone. How the filter works.

Neither is cleverer. The difference is who owns the decision. A score is the tool’s judgment and you tune it. My rules are yours, and half of them live in your repository. The repo owns skip labels and path rules in its own .marketing.yml, so they move with the branch and get reviewed like code. The app owns voice, ICP, hashtags and destinations. A block in a PR body can make posting stricter, never looser, because a field anyone can type in should only ever be able to shut something up. Where each rule lives.

The second thing narrowing buys is voice. Every draft is aimed at a stored ICP, and every draft is attributed to a named voice, brand or person. Copy in a person’s voice never auto-publishes, because a machine posting in my name while I sleep is a different product from one posting as a company.

Side by side

Which tool does which job

Read the platforms row twice. Thirteen against five is not a gap I am closing. It is the product decision, stated out loud.

Honesty

Where we genuinely overlap

More than the platform count suggests.

Both of us start from GitHub webhooks rather than from you opening an app. Both of us read some diff context instead of posting a commit message verbatim. Both of us filter, and both of us know filtering decides whether the tool survives. Both of us write per-platform copy, show it as a draft first, and publish natively, so nobody is copying text into a browser tab.

On X, Bluesky, LinkedIn and Discord we are pointed at the same accounts doing the same job. If those are your only networks, the platform count stops mattering and the decision comes down to filter depth, voice control and whether images matter to you.

Not us

When BuildCast is the right answer

I would rather say this here than in an email three weeks in.

• Your audience is on a consumer network. Instagram, TikTok, Facebook, Pinterest, YouTube, Threads, Reddit, Tumblr. I post to none of them, on purpose, and I will not be adding them. If that is where your people are, this is not close.
• Images are part of the post for you. Their drafts carry images you can swap in the editor. Mine are text and links. On a visual network that is the whole game.
• You want issues and releases to become content too. A shipped release or a well-written issue is real material and my trigger ignores both.
• You do not use pull requests much. If most of your work lands as direct commits, my trigger barely fires.
• You want to start at zero. Their free tier covers one project, three repos, three platforms and fifty posts a month, and Pro is fifteen dollars. What this costs.
• You would rather tune one dial than maintain rules. Signal scoring is less to think about than a ladder plus a YAML file, and less to think about is a real feature.

None of that is a knock on the tool. It is a different job, and a tool that claims to do every job is lying about one of them.

Together

Running both

Split by network, not by repository. BuildCast owns the wide surface, the visual platforms and anywhere a caption and an image do the work. Merge & Tell owns the developer-facing five, where diff-level detail makes the post worth reading and a character limit is a constraint rather than a suggestion.

Nothing in the way I publish assumes I am the only tool touching an account. Accounts are grouped into named social sets, and a repository pointed at a set that does not exist publishes nothing. It never falls back to everywhere, so the overlap you allow is the overlap you get. What I do with your tokens.

If you would rather see it than read about it, paste a pull request of your own and read what comes back. The bottom of the home page is my own accounts, live, posting what this wrote about its own merges.