Case study · Automation · Web platform

Two brands, three networks, one operator. A week's posting where the voices never blend.

Postflow is a multi-brand social pipeline we built for our own use. We built the pipeline that writes each brand's week in that brand's own voice, sizes the caption for every network and publishes on Tuesday at 09:00 in the brand's timezone, and the dashboard one person runs it all from.

Postflow's Overview dashboard: a sidebar with Overview, Compose, Review and Queue and a list of two brands; a This week panel naming the brand that needs attention, with two posts that didn't finish and one that didn't go out; an at-a-glance count of brands settled, posts awaiting review and items needing fixing; a Needs fixing list with Try again buttons; and a status card for each brand, one showing a publishing failure and the other not configured.

The brief

The platform had to write, size, schedule and publish each brand's week for a single operator, and keep the outcome on every network visible.

  • Two voices, kept apart Each brand's post had to be written in that brand's own voice, with no blending between the two.
  • Per network, not per post Every network a post goes to needed its own caption size, and its own status, error and retry count.
  • On each brand's clock The week's post had to go out on Tuesday at 09:00 in that brand's own timezone.
  • No minute-by-minute polling The system could not poll every minute, which would bill 43,829 runs per workflow.

The dashboard had to open on one question: what needs me right now?

What we built

A content pipeline and the operator's dashboard over it, built on Next.js and Supabase.

  1. Writing in each brand's voiceThe week's post is written separately for each brand, in that brand's own voice.
  2. Captions sized per networkEach post's caption is sized for every network it goes to.
  3. A schedule and a queuePosts are scheduled for Tuesday at 09:00 in each brand's timezone, and publishing work waits in a queue where a worker claims a row before acting on it. Two workers cannot take the same row, by construction.
  4. Three networks, tracked apartEach post holds a separate status, error and retry count for each of its three networks.
  5. The operator's dashboardThe operator works from a dashboard with Overview, Compose, Review and Queue screens and a list of the brands beneath them. Each brand carries its own status, such as a publishing failure or not yet configured.

What changed

  • A failure stays on its network When a post fails on one network, the failure is recorded against that network, and the post's other networks keep their own status.
  • The week opens on what needs attention Overview opens on this week: which brand needs the operator, and a Needs fixing list with Try again on each item.
  • Both brands on a few hundred runs The whole system, both brands and every network, runs on around 390 automation runs a month.
The results

The numbers.

~390
Automation runs a month

~390 automation runs a month cover the whole system, where minute-by-minute polling would bill 43,829 per workflow.

3
Networks tracked per post

Each post is tracked on 3 networks independently, each with its own status, error and retry count.

0
Double-claims possible

Two workers cannot take the same row, so double-claims are impossible by construction.

The stack
Next.jsReactTypeScriptSupabasePostgreSQL

Running social for several brands and keeping each voice apart by hand?