One idea, adapted per platform, not duplicated across them

The promise of cross posting is that one piece of writing becomes five posts for free. The reality is that some of those five will be rejected by the platform, some will be accepted and read badly, and on at least one platform the practice itself is against the rules.

The alternative is not writing five separate things. It is writing one idea and deciding, deliberately and in advance, what each destination changes about it.

X publishes automation rules that name posting duplicative or substantially similar content across multiple accounts you control as a distinct problem. That is not advice about engagement. It is a policy about what you may do with accounts you own, and it applies to a scheduler exactly as it applies to a person.

This alone rules out the naive design where one text field fans out to every connected account. If you run more than one account on a platform with a rule of this shape, the safe default is one adapted variant per account, and the tool should make writing that variant the easy path rather than an override.

Before tone, before length, there is a structural question: does this destination accept the kind of thing you made. The answers are not consistent, and they are not negotiable.

A second class of difference is procedural rather than structural. Several platforms require an approval step before an application may publish on a real account, and the gate is often about what visibility you are allowed to set rather than whether you can call the endpoint.

• TikTok's content sharing guidelines describe the review that governs what an application may do with post visibility, which is a different question from whether the upload succeeds.
• YouTube's Data API documents an audit for API clients, and until it is passed the visibility an uploaded video may be given is restricted.
• LinkedIn's community management surface requires an access review before an application may post on behalf of an organization.

For a publishing plan this means the launch date of a destination is the date its review completes, not the date the code works. Treat every gated destination as unavailable in the calendar until it is not, and say so out loud rather than leaving a column that silently never fills.

The practical technique is to separate the idea from its expression, and to write the idea in a form that no destination will ever receive.

1. 01Write the source note. One claim, the reason it is true, and the one thing a reader should do or think afterwards. This never gets published anywhere.
2. 02Decide the shape per destination from the table you wrote earlier: text, image with caption, thread, document, video.
3. 03Write the opening line per destination. This is where nearly all the adaptation lives, and it is usually two minutes of work.
4. 04Cut or extend the body to the destination, and move the link to where that destination expects it.
5. 05Write the media description per destination, in the field that destination actually has.

Steps three to five are the only per destination work, and they take far less time than the first two. The saving that cross posting promised is real. It just comes from sharing the thinking, not from sharing the string.

Adaptation goes wrong in the other direction too. A team that rewrites everything ends up saying five slightly different things, which is worse than saying one thing five ways.

Everything above rests on facts about platforms, and platform facts expire. Keep one sheet per destination with the accepted shapes, the account type required, the review status, and the date each line was last checked against the official documentation. Not a blog post. The documentation.

A dated sheet turns an argument about what a platform allows into a lookup, and it tells you which lines are old enough to be worth rechecking before the next planning cycle.