The real cost of building social media integrations in-house

We're scoping this to six platforms a typical multi-tenant SaaS product would prioritize first: Instagram, Facebook Pages, TikTok, LinkedIn, X, and YouTube. That set is deliberately the harder half — each requires either a formal approval gate, a non-trivial publishing flow, or both. Platforms like Bluesky, Mastodon, and Telegram are meaningfully cheaper to integrate (no App Review, simple token or bot-based auth) and are excluded here to keep the estimate focused on where the real cost sits. For the full list of platforms "post everywhere" actually implies, see how many integrations it takes to cover every major network.

We're also scoping to a single engineer's work of building the publishing path per platform — connect, validate media, publish, track delivery, handle errors and token refresh — assuming the shared infrastructure (durable job queue, idempotency, encrypted token storage) is being built once and reused, not rebuilt per platform. That shared layer is its own project, covered separately below, because treating it as a rounding error is one of the more common ways these estimates come in low.

Before any of the six platforms above will let your app publish to a customer's real account, most of them require passing some form of review. This time is calendar time, not engineer-hours — it can run in parallel with development, but it still gates your production launch date, and it is the single most variable line item in this whole estimate.

Meta's App Review for Instagram content publishing is the one we have the most concrete data on: our dedicated walkthrough of the process found reported turnaround anywhere from a few days for a clean, well-prepared submission to several weeks during high-volume periods, with at least one round of rejection-and-resubmission common even for well-prepared apps. Facebook Page publishing (pages_manage_posts) is reviewed on its own separate clock from Instagram, even though both are Meta permissions — passing one does not fast-track the other.

TikTok requires an audit to move a client from unaudited to audited status before it can post publicly to non-private accounts at normal caps — see what actually changes after TikTok audit. TikTok does not publish a fixed SLA either, and developer reports on turnaround vary widely enough that we won't repeat an unverified number here — budget for it the same way you would Meta's review: assume weeks, not days, and build the rest of your integration against TikTok's sandbox in parallel. LinkedIn's Community Management API access process is a vetting flow rather than a single review: company page verification, a development-tier grant, then a standard-tier upgrade that requires its own screencast and use-case review — each stage adds calendar time before the last stage can start. X and YouTube are comparatively lighter here: X's current API access is a pay-per-use credit model rather than an approval queue (more on that in our 2026 API changes reference), and YouTube gates on a Google Cloud quota increase request rather than a content review, which is its own process worth budgeting for separately.

For each platform, the actual engineering work splits into roughly the same five buckets, even though the specifics differ every time: the connection and OAuth flow, token storage and refresh logic, media validation against that platform's real format and size rules, the publish flow itself, and delivery-status handling (webhook, polling, or both). The ranges below are engineer-days for a competent generalist backend engineer building against each platform's sandbox or test environment, assuming the shared queue and token-encryption infrastructure already exists.

Summed, that's roughly 53-88 engineer-days of platform-specific build work across six platforms — call it 2.5 to 4.5 engineer-months for one person working sequentially, less in calendar time if more than one engineer works platforms in parallel. This is happy-path estimation for first-time correct behavior; it does not include the debugging time that shows up once real customer accounts start hitting edge cases your test account never triggered.

None of the per-platform numbers above work without the five systems covered in how to build a social media scheduler: encrypted, per-platform-aware token storage; a durable job queue that survives restarts and doesn't double-fire across instances; idempotent retries with a stable key; and an aggregate-plus-per-target delivery status model. Building that layer to a production-reasonable standard — not a prototype — is its own project, and a reasonable range for a small team is another 15-30 engineer-days, largely front-loaded before the first platform integration can rely on it.

Put together, a realistic all-in estimate for six platforms plus the shared layer lands around 68-118 engineer-days, or roughly 3.5 to 6 engineer-months of raw build time — before the calendar delay that App Review and TikTok's audit add on top, which can push a first production launch out by several additional weeks depending on how the review cycles land.

A build estimate that stops at "launch" understates the real cost, because platform APIs keep changing after you ship. In 2026 alone: Meta shipped Graph API v25.0 in February and v26.0 in July, with a 47-endpoint commerce removal landing in October and older versions expiring on a rolling schedule; LinkedIn is sunsetting an entire Marketing API version in August; and X replaced its pricing model outright in February, then adjusted specific per-call rates again in April. We track these in more detail in our living 2026 API changes reference. None of that is unusual — it's the normal cadence of six independently-operated platform APIs, and it means "done" is not a state this kind of integration layer ever reaches.

We won't put a false-precision number on ongoing cost, because it depends heavily on how many platforms you run and how much slack your team has — but a reasonable planning assumption is that each platform integration needs somewhere between half a day and a few engineer-days of attention per quarter on average, spread unevenly: some quarters nothing breaks, others (like a version sunset or a pricing model change) demand a focused sprint. Multiply that across six platforms and it's a standing, non-zero claim on engineering time for as long as the integrations are live — not a one-time cost you finish paying.

This is a build-effort estimate, not a total cost of ownership. It excludes: the product and UX work of actually exposing scheduling, connection management, and delivery status to your users; customer support time when a customer's connection breaks; the security review a token-custody system reasonably deserves before it touches real customer credentials; and any compliance work specific to your industry or region. It also assumes a competent generalist engineer already comfortable with OAuth and async job processing — a team building this for the first time should expect the low end of every range above to be optimistic.

If you want the other half of this analysis — the scenarios where building this in-house is genuinely the right call, not just the more expensive one — see our build-vs-buy framework.