Not a content studio. A pipe from the merge to the account.
ShipCast reads your merged pull requests and writes tweets, threads, LinkedIn posts, release notes and executive summaries out of them. It reads the real diff, not just the PR title, and its own copy says nothing posts automatically. You review everything. Merge & Tell starts from the same event and the same diff, then keeps going: through a filter, into per-network copy, into your own connected accounts, on a queue. We overlap almost exactly on the first half and almost not at all on the second.
The short answer
We agree on the trigger
ShipCast and I agree on the hardest thing in this category. A merged pull request is the best trigger anyone has, and the diff is the only honest input. That is a real position, and most tools in this space do not hold it.
Where we split is the finish line. ShipCast hands you content. Its FAQ is blunt that you still review and post, and it puts that in the “not a good fit if” section rather than burying it. Whether posting means clicking publish in their app or pasting into X, the site does not spell out, so I will not claim it either way. On my side, approved copy goes out through my own queue to accounts you connected here, with slots, a minimum gap, retries with backoff and a stop button. How the queue behaves.
So ShipCast is a content problem solved. Merge & Tell is a distribution problem solved, with the content step included, because you cannot distribute nothing.
Why the category matters
The draft is the easy half
The reason your calendar is empty is not that writing is hard. Nobody triggered anything. Four things shipped last week, none of them turned into a post, and better drafting fixes none of that, because the drafting never started.
Trigger on merge and the problem changes shape. Both of us do that. But once you generate on every merge, a second problem shows up, and it decides whether the tool survives month two. Most merges are not announcements.
That is where most of my engineering goes. Bot authors, lockfile churn, paths marked publish: never, a marketing:skip label. All dropped before a draft exists. Under ten meaningful lines the diff counts as trivial, and a three-line fix the brief calls major can still post. Chores, refactors and the smaller user-facing news skip. Nothing posts them. I batch by hand when I want the pile. ShipCast’s site does not discuss filtering, which does not mean it has none, only that it is not part of the pitch. Mine is, because a tool that turns every merge into a post is worse than staying quiet. How the filter works.
The rules split by owner. The repo owns skip 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. Where each rule lives.
Side by side
Which tool does which job
| The job | ShipCast | Merge & Tell |
|---|---|---|
| What starts it | A merged pull request | A GitHub webhook, on merge |
| What it reads | PR title, description, commit messages, the diff | The diff of the merged pull request |
| Deciding something is not worth posting | Not described on their site | The filter ladder, before a draft exists |
| Small changes | Weekly release notes, delivered Mondays | Scored for size, not held. Major news posts even when short. Chores, refactors and minor news skip. You batch by hand, on every plan. Opt-in weekly digest of every merge, still a draft you approve |
| Where the copy goes | You review and post | Your own connected accounts, after you approve |
| Channels | Twitter, LinkedIn, plus blog drafts | X, Bluesky, Mastodon, LinkedIn, Discord, Slack, WordPress, plus a changelog feed in Atom and JSON. Threads and a blog draft are optional, per repo or social set |
| Per-network copy | Tweets, threads and LinkedIn posts | Written per channel, to that network’s own limit. Optional thread on X, Bluesky and Mastodon |
| Who the copy is aimed at | A product, audience and tone you describe once | A stored ICP, applied to every draft |
| Who appears to be speaking | Your voice, learned from what you tell it | A named voice, brand or person, resolved per channel. Copy in a person’s voice never auto-publishes |
| Publishing behavior | Nothing posts automatically | Slots, a minimum gap, retries with backoff, a stop button |
| Where the tokens live | Not described on their site | Encrypted server-side. They never reach the browser |
| Reporting to stakeholders | Executive summaries in non-technical language | Opt-in exec summary drafts from the week’s merges. Still review, then publish |
| What it measures | Not described on their site | Kept-rate, how much of what it wrote you published without rewriting |
Two rows are worth reading twice. I now draft the weekly notes and the exec summary they built a product around. They still win if that document is the whole job. Kept-rate is a thing I do and they do not. Four rows say “not described on their site”, which means exactly that and not that the feature is missing.
Honesty
Where we genuinely overlap
Almost everything before the word publish.
Same trigger. Same input. Both of us read the actual diff rather than guessing from a PR title, which matters more than it sounds, because a title like “fix edge case” is not content and a diff usually is. Both of us write per-network copy, put a human in front of it, and aim at people who ship a lot and tell nobody.
Take the first half of either product and you would struggle to tell them apart in a screenshot. I would rather say that than pretend the category has one honest answer in it.
Not this one
When ShipCast is the right answer
I would rather you read this here than work it out three weeks in.
- You want the weekly release notes and the stakeholder summary to be the product, not a side-effect of posting. I compile both from merged PRs now, as drafts you still approve. How that lands. Their version is a content studio for a team. Mine goes through the same review queue as a tweet. If the document is what you came for, buy that.
- You are a team, not a person. Their copy says “your team ships 15 PRs a week” and the product is shaped around that. I am built for one person with too many repos.
- You want a human hand on every post anyway, and would rather not hand account tokens to a third party. If no post of yours will ever go out on its own, the publishing half of my product is weight you pay to carry.
- Your networks are Twitter and LinkedIn and that is the whole list.
- Budget decides it. They are free while in beta, no card. I cannot compete with free and will not pretend otherwise. What this costs.
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
You can still split it. Their studio is built for a team that wants those documents as the work. Mine writes the same two shapes, then the copy has to land in an account you connected here. If you already like how they write the week up, keep them for that and let me post.
Nothing about the way I publish assumes I am the only tool touching your accounts. 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. What I do with your tokens.
If you want to check any of this before believing me, the bottom of the home page is my own accounts, live, posting what this wrote about its own merges.
Questions
Short answers
What is the difference between Merge & Tell and ShipCast?
Both start from a merged pull request and read the real diff. ShipCast hands you content: tweets, threads, LinkedIn posts, release notes and executive summaries, which you review and post. Merge & Tell keeps going, through a filter, into per-network copy, and out to your own connected accounts on a queue.
Does ShipCast post automatically?
Its own copy says nothing posts automatically, and you review everything. Its site does not spell out whether posting means clicking publish in its app or pasting into X.
When is ShipCast the better choice?
When the weekly release notes and the stakeholder summary are the whole job. When you are a team, not a person. When you want a human hand on every post and would rather not hand account tokens to a third party. Or when budget decides it, since ShipCast is free while in beta.
You pick the grouping.
You were going to merge the PR anyway.