Social Media Publishing & Automation Suite

A marketing operation running multiple brand accounts was juggling native platform tools, shared passwords and content calendars in spreadsheets — slow, error-prone and impossible to supervise. Commercial tools priced per seat and per account made consolidation expensive at their scale. We built a self-hosted publishing suite: multi-platform scheduling from one dashboard, an approval workflow so juniors draft and managers release, a shared calendar, and per-account reporting. Credentials live in one secured system.

The challenge

Managing several brand accounts across several platforms produces a specific chaos. Credentials get shared over chat because somebody must post while a colleague is away. The calendar lives in an always-slightly-stale spreadsheet. Nobody can answer the two questions a manager cares about: what is scheduled this week, and who approved it. Native tools have no concept of a draft awaiting approval across a portfolio, so approval happened informally over messages — which means inconsistently.

Our approach

We were explicit that this is a category where buying is usually correct. The case for building rested on the seat-times-account pricing curve at their scale, credentials held in their own infrastructure, and a draft-review-release workflow mattering more than feature breadth. We would not recommend it to a team running three accounts. Architecturally, a publishing tool is a queue system, not a content app. The interesting engineering is reliable delivery: a post scheduled for 9am must go out at 9am, and when an API returns a rate limit or expired token, the system must retry sensibly, surface the failure to a human, and never silently double-post.

Architecture and key decisions

The adapter layer matters. Platform APIs change, deprecate and restrict without warning, each with its own media constraints and auth lifecycle. Isolating each behind an adapter keeps a breaking change to one module.

How we sequenced the work

One platform first, end to end: authentication, token refresh, scheduling, publishing, failure handling. Proving the full lifecycle on one integration exposes every architectural weakness before it is replicated four times. Then queue hardening — retries, idempotency, failure surfacing — because a publisher that fails silently destroys trust permanently. Then further adapters, the approval workflow and shared calendar, then analytics. Migration off shared passwords ran alongside, each account reconnected through official authentication and old credentials rotated.

What to look for if you're commissioning this

Check the economics honestly first. Below a certain number of seats and accounts, a commercial tool is cheaper and better than anything you will build; our build vs buy tool exists for this comparison, and for most teams the answer is buy. If you do build, ask how the system guarantees a scheduled post publishes exactly once, what happens when a token expires overnight, and who pays for the maintenance API changes require — that last question separates a realistic proposal from an optimistic one. Ask where tokens are stored and how they are encrypted; treat it as a security review, per cybersecurity services. Self-hosting also means somebody must operate it, which pairs with managed IT services.

Typical cost and timeline

General ranges for this class of build, not this client's figures. A suite covering two or three platforms with scheduling, an approval workflow and a shared calendar typically runs three to five months. More platforms, richer analytics and media handling extend that. The cost most people miss is ongoing: API changes require continuing maintenance, so budget a permanent retainer, not a one-off build. Against that, per-seat fees disappear, which is what makes the arithmetic work at scale. See our cost estimator and pricing.

The outcome

Brand accounts run from one console with a publishing cadence that survives holidays and handovers. The approval step ended off-brand surprises, because release is a deliberate act by someone accountable. Per-seat licence fees ended entirely.

Frequently asked questions

Should I build a social publishing tool or buy one?

Buy, unless you have a specific reason not to. Commercial tools are mature, maintained against platform API changes, and cheaper than a build for most teams. Building becomes defensible when seat-and-account pricing at your scale is punitive, when you need credentials in your own infrastructure, or when your approval workflow fits no product's model.

What happens when a social platform changes its API?

Something breaks, sooner or later — a certainty, not a risk. Isolating each platform behind its own adapter limits the blast radius to one module, and monitoring publishing failures means you hear it from the system, not a client. The practical implication is that a self-hosted publisher needs a permanent maintenance budget.

How do you stop a scheduled post going out twice?

With idempotency keys on each scheduled item and a queue that treats delivery as at-least-once with deduplication at the boundary. Retries after ambiguous failures — where the platform may or may not have accepted the post — are the dangerous case, and handling them properly is the subtle engineering problem in a publishing tool.

Is self-hosting social account credentials safe?

It is safer than shared passwords in browsers, which is the realistic alternative, provided tokens are encrypted at rest, held server-side only, scoped to minimum permissions and revocable per account. It does mean you own that system's security, so operate it as seriously as anything else holding credentials that publish as your brands.

If you run multiple brand accounts on shared passwords and spreadsheets, book a free 30-minute technical session via contact us. To have the build-or-buy call assessed independently, see fractional CTO.