Skip to content
All engagementsEngagement note

Content operations platform

Replaced three offshore workflows with a typed automation pipeline owned by an internal platform team.

  • Fortune 500 retailer
  • Automation
  • 12 weeks
Duration12 weeks
Team1 senior engineer embedded in the platform squad
HandoverInternal platform team, on-call ownership
Disciplines
  • Durable queues
  • Typed contracts
  • Design system
  • Observability
Decide

Best fit when.

  • 01Multiple vendor workflows need to be wrapped — not replaced — behind one typed surface.
  • 02Your team owns the operational surface long-term but does not yet own a workflow-engine codebase to extend.
  • 03Every stage requires an audit trail compatible with your retention policy.
Context

What was happening.

Three offshore vendor workflows produced product copy, asset variants, and translated content for a large catalog. Each workflow had its own ticketing surface, its own SLAs, and no end-to-end view. Errors discovered late were expensive — by the time a translation regression surfaced, the asset was already in a marketing campaign.

Closing scope around this needed the discipline we describe in our writing on how we scope an AI engagement — vendor surfaces that 'might as well' have been included stayed out, on purpose, and the omission list was as long as the deliverable list.

Constraints

What we were holding to.

  • Existing vendor relationships could not be cut mid-engagement; the platform had to wrap them.
  • The internal team had no prior workflow-engine surface to extend; the platform had to be greenfield, but small.
  • Every stage needed an audit trail compatible with the brand's retention policy.
Approach

How we built it.

Typed contracts at every stage boundary

Every stage of the pipeline — intake, generation, review, publish — exchanged typed payloads with explicit invariants. Vendor adapters lived behind those contracts so a vendor swap is a code change to one adapter, not a workflow rewrite.

Durable, idempotent jobs

Stages ran as durable jobs with explicit retry and backoff policies. Idempotency was a first-class invariant — every job could be replayed safely, which made staging behaviour match production behaviour for the first time.

An operator UI built from the design system

Reviewers worked through a small operator UI built on the client's existing design system. We did not introduce new components or visual language — accessibility audits and brand reviews were already done.

Handover

What we left with the client.

  • A deployed pipeline owned end-to-end by a named platform team.
  • Typed IO contracts at every stage boundary, versioned and documented.
  • Idempotency and retry policy written down, with a runbook covering the failure modes we saw in staging.
  • Dashboards and alert routes wired to the platform team's existing on-call rotation.