The scheduling part of a social media scheduler is a weekend. A queue, a worker, a cron. That’s genuinely not hard, and it’s why the estimate is always wrong.
Everything expensive is on the other side of it.
The part that’s easy
A table of posts with a scheduled time, a worker that wakes up, finds due posts and publishes them. Add a retry and you’re done.
If you’re building this as a learning project or for one platform you control, stop reading. The rest of this is about what happens when real accounts and multiple platforms are involved.
The data model you actually need
More states than people expect:
- draft, created but not queued
- scheduled, queued for a time
- processing, sent to the platform, outcome unknown
- published, confirmed
- failed, with a reason
- partial, published to some targets and not others
processing exists because several platforms accept a post and publish asynchronously. A 200 is not a publish, and the outcome arrives later out of band. Without this state your UI claims success and is sometimes wrong.
partial exists because one post usually targets several platforms. Three succeed, one fails. Neither “published” nor “failed” is true, and forcing it into either produces a product that lies to its users.
You also need per-target rows rather than one status on the post, because the failure is per platform.
Time zones
Store the instant and the IANA zone, not an offset.
“Every weekday at 9am local” is a different UTC instant before and after a daylight-saving change. Storing only UTC works until March, then everything drifts by an hour and the bug reports are confusing because it’s correct half the year.
The platform work
This is where the estimate breaks. Per platform:
A separate OAuth flow. Different scopes, different token lifetimes, different consent screens.
A separate refresh job. This is the one that hurts. Tokens expire, refresh fails silently, and nobody discovers it until a scheduled post doesn’t go out. You need scheduled refresh, monitoring for refresh failure, a broken-connection state and a reconnection flow. That’s more work than the OAuth flow itself.
A separate media pipeline. One platform fetches a URL, one wants a resumable chunked upload, one wants specific dimensions or codecs. You’ll be hosting and possibly transcoding.
A separate rate limit, with its own window and its own behaviour when exceeded.
App review. Several platforms gate publishing behind a review involving your app, a privacy policy and sometimes a demo video. That’s calendar time you don’t control, and it can be refused.
Perpetual change. API versions get deprecated, fields renamed, permissions tightened, on the platforms’ schedules. Every one is unplanned work with a deadline you didn’t set.
Multiply by the number of platforms. Then keep paying it, forever.
The publishing rules
Beyond delivery, the thing users actually want is not publishing something that will be rejected. That means encoding per platform:
- Character limits
- Media counts, sizes, formats, durations, aspect ratios
- Which post types require media
- Which formats exist at all
And validating on create rather than at publish, because a failure at publish time is one the user finds out about after the moment has passed.
Build it if
- You publish to exactly one platform, permanently
- Publishing is your product and the differentiator
- You need depth well beyond publishing, like ad management
Don’t build it if
Publishing is a feature of something else you’re building and it reaches three or more platforms. The cost isn’t the build, it’s the maintenance, and the maintenance scales with platform count while your team doesn’t.
The alternative
One integration, where the platform churn is somebody else’s problem.
- Base URL:
https://app.bulkpublish.com - Auth: API key, or OAuth 2.1 if you act on your users’ accounts
- Surface: 59 documented endpoints
- Platforms: 15
- Validation: limits checked on create, not at publish
- SDKs: Node and Python, plus a Postman collection and an MCP server
| Free | Pro | Business | |
|---|---|---|---|
| API requests/day | 30 | 5,000 | 50,000 |
| API keys | 1 | 5 | 10 |
The short version
The queue is a weekend. The states, the time zones, and one OAuth flow plus one refresh job plus one media pipeline per platform are the actual project, and the platform churn means it never finishes. Build it if publishing is your product or you’re on one platform forever. Otherwise the integration you don’t maintain is worth more than the one you do.