Sending a post to a network is one call. The hard part starts before it and after it: fourteen networks with different limits, formats and post types, a status that is neither a yes nor a no when one of them fails, and a retry that has to work out whether the post went out after all before it dares send anything again.
The send is the trivial part
If you only ever had to publish one piece, on one network, once, you would need neither us nor anybody else: it is a single call, it takes an afternoon, and it works. Every difficulty a publishing calendar has lives in the three words we just removed from that sentence, which are one, one and once.
The first time this product published to several networks from a single piece, the part nobody had designed was what to say when two networks accept and one refuses. A system that can only tell good from bad has to pick which of the two lies it tells, and both are expensive. Call it a failure and somebody republishes what is already live. Call it a success and nobody finds out a network is missing until the client asks.
That question, rather than the send, has shaped almost everything underneath the calendar. What follows is what we learned answering it.
Fourteen networks, fourteen different contracts
The first surprise is that publishing does not mean the same thing in any two places. Each network has its own caption limit, its own file count, its own post types and its own slots that do not exist elsewhere. A piece is not an object you copy: it is an object you translate into fourteen contracts, and it fails as soon as one of them does not add up.
| What changes per network | Where | What it forces you to do |
|---|---|---|
| Caption limit | From 250 on Snapchat to 40,000 on Reddit | Write for the narrowest network in the group |
| Files per piece | Exactly one on YouTube, Pinterest and Snapchat; up to 35 on TikTok | A carousel does not travel everywhere |
| Post types | Feed, reel, carousel and story do not exist on all of them | The type is chosen per network, not per piece |
| Automatic first comment | Instagram, Facebook, LinkedIn and YouTube | On the other ten a person adds it by hand |
| Alt text | Up to 1,000 characters, 500 on Pinterest | Six networks store it and the rest ignore it silently |
The decision that came out of that table is that the place to check all of it is the composer, before anything is scheduled, and not the moment of sending. A warning while you are writing costs ten seconds. The same warning at nine on a Tuesday morning, when the piece should already be out, costs the morning. What each network actually accepts is collected in supported social networks, and the dimensions for each format are in social media image sizes.
A status that is neither a yes nor a no
A post scheduled to five networks does not have one status, it has five. That is why a piece here is a piece with targets, each target carrying its own result, and why there is a status almost no tool shows: partial. It went out on four, it failed on one, and that is neither a failed post nor a published post. It is exactly what it says.
Having that state written into the model rather than only into the screen changes three things. The piece stays on the calendar instead of vanishing, with the reason beside it and the specific network named. A retry can touch only what failed, without republishing on the four that worked. And the team can see at a glance what is still outstanding, which is the only thing that matters once you are running twelve brands.
A silent failure is worse than a failure. A failure gets fixed that morning. A silent failure gets discovered when somebody outside the company tells you their post is not there.
Retrying is harder than sending
This is the part we did not see coming. A retry looks like the easy operation, the one that does the same thing again, and it turns out to be the dangerous one, because the question you have to answer first is not "did it fail" but "did it fail after it had already worked".
A network can accept a post and drop the connection before confirming it. From the outside that is indistinguishable from a clean failure, and the two possible answers do not cost the same: not publishing something leaves a gap, and publishing it twice leaves a duplicate on an account belonging to somebody who trusted you. So before resending, the system asks the accounts what they are holding. If the answer is clear, it acts on it. If it is not, it does not guess: it marks that target unverifiable and asks you to confirm the post did not go out. We would rather ask an awkward question than duplicate something quietly.
Underneath there are two more of the same kind. Two people pressing retry at the same moment have to produce one copy and not two, and that gets settled by the database acting as referee rather than by an optimistic check that fails on exactly the day everybody is in a hurry. And some failures are not failures but ceilings: some networks enforce a daily posting cap shared across every tool, so a piece turned away for that reason is not marked failed for good. It is parked with an appointment for when the cap resets, with a limited number of attempts so that nothing retries itself forever.
The file you upload once
The other half of publishing at scale is not the text, it is the weight. A video going to four networks does not get uploaded four times: every file you attach is copied into the brand's own library on the server, and reused from there. That sounds like an infrastructure detail, and in practice it is the difference between scheduling a week of work and spending the morning watching progress bars.
Formats behave like caption limits: what one network accepts another refuses, and the place to sort that out is before scheduling rather than at send time. The practical consequence for somebody using this daily is that the unit of work stops being one post per network and becomes one piece, which is where the time to hold a cadence comes from. What yours should be and how to work it out is in how often to post.
Everything in this article happens in one place in GoFeed.
Try it freeWhat we decided not to do
Publishing at scale has three obvious shortcuts, and all three are ruled out in writing.
- We do not write the caption for you. It is copied as it is, or it takes the prefix and suffix you typed, or it stays empty. There is no text generation and no image generation at any point in the journey, and that absence is a product decision rather than a gap.
- There is no recycling queue. Republishing the same piece to the same network over and over is a pattern in this category that does not exist here, and not for lack of time: a uniqueness constraint in the database makes it impossible on purpose.
- Not every network is here. There are fourteen and X is not one of them, in either direction, organic or paid. Saying so in the table above is more useful than leaving a checkbox that answers to nothing.
There is a fourth that is a rule rather than an absence: nothing this product publishes may come back in through the door of what this product detects. That sounds obvious until you have an automatic rule and a calendar pointing at the same account, and then it is the difference between one piece and the same piece twice.
What is left once the hard part is gone
When any of this works, you do not notice it. The piece goes out on time on the networks it was meant for, the caption fits the narrowest one, the alt text is where it gets stored and the video was uploaded once. The visible work is the work that came before: deciding what to say and who says yes to it.
That second half has a mechanism of its own. With approval switched on, the piece waits for one yes, from the team inside the app or from the client in their portal, and whichever arrives first is the one that counts. And a piece whose hour passed while it was waiting does not go out late: it is parked for rescheduling, because a post at the wrong hour is almost always worse than a post that did not go. How it all fits together, brand by brand, is on the calendar and publishing page, and the full journey of a piece from draft to report is in social media scheduling.