Case Study – Media Engine

From Manual Production to Campaign-Driven Rendering at Scale

This case study demonstrates the RS Tech Hub Media Engine applied to a multi-client production workflow — social media assets and corporate documents rendered across concurrent client campaigns, with brand consistency enforced by the system rather than by manual review.

Industry: Marketing & Creative Agency
Company size: Small-to-mid agency, multiple concurrent client accounts
Engagement type: Product delivery — self-hosted platform deployment
Deliverable: Media Engine (containerized rendering platform)

The Situation

A creative agency producing both social media content and corporate documents — contracts, product one-pagers, marketing collateral — for a growing client roster was running production entirely through manual design work. Every asset, regardless of client or type, went through the same path: a designer opened a project file, applied that client's branding by hand, exported, checked it against brand guidelines, and repeated the process for the next asset.

The agency's client count was growing. Its production process was not built to grow with it. Every new client added a fixed amount of manual work per asset, with no way to absorb that growth except by adding headcount.

The Problem Diagnosis

Before any development began, the agency's production workflow was mapped end to end. The analysis identified four compounding failure points:

No campaign structure. Work arrived as ad hoc requests rather than defined units with a clear state. There was no way to see, at a glance, which pieces of content for which client were in progress, awaiting approval, or finished.

Brand risk at the point of production. Branding was applied manually, per asset, by whichever designer picked it up. Logo versions, color values, and typography depended on that person remembering the current guideline — a dependency that failed quietly and inconsistently across a growing client list.

Document and creative work sharing one ad hoc process. Corporate documents — contracts, product documentation — were produced through the same informal, non-repeatable process as social content, despite carrying a much lower tolerance for error.

No isolation between clients. Client assets, templates, and content lived without a structural boundary between them, creating both a data-management risk and a ceiling on how many clients the same team could handle without confusion.

The root cause was consistent across all four: production had never been engineered as a system. It ran on individual designer discipline, which is not a process — it's a dependency on people not making mistakes.

The Approach

The engagement began with process design, not software development. The full production workflow was modeled as a campaign lifecycle before any rendering logic was built: campaign registration, preparation, release to processing, rendering, and completion, each mapped to an explicit status.

A strict status policy was defined — NEW, PREPARED, READY, LOCKED, COMPLETED — with each transition mirrored by moving a campaign's input and output files into the corresponding storage folder, so the state of any campaign is visible directly from the filesystem, not only from an internal database.

Brand enforcement was designed as an architectural constraint, not a review step: one theme layer per client — logo, color palette, typography — injected into every template for that client, with no path for a render to bypass it.

The platform was built as a production-ready, containerized system: TypeScript and NestJS for the application layer, PostgreSQL for campaign and asset data, Redis for the render queue. The video renderer runs as a separate container from the main application, so a template change can restart the render engine independently — without restarting the API, the queue, or any in-flight document rendering.

What Was Built

Campaign & Status Lifecycle
Every rendering job — social asset or corporate document — is organized under a campaign, defined in JSON and tracked through NEW, PREPARED, READY, LOCKED, and COMPLETED. The PREPARED → READY transition is configurable per client: automatic for some, gated behind human approval for others. Multiple campaigns run concurrently per client, each independently visible in its own state.

Document Rendering
Contracts, product documentation, and marketing collateral render from structured data against versioned templates, output as PDF. The same pipeline that renders a client's social content renders their contracts, under the same status discipline.

Motion Rendering
Text-animation video for social channels renders per platform-specific presets — aspect ratio, resolution, duration — driven by configuration rather than built per asset.

Brand Enforcement
Each client's brand identity is defined once, in a dedicated theme layer, and inherited by every template used for that client. A render either matches the client's brand or doesn't produce output — there is no manual step where an off-brand asset can pass through unnoticed.

Multi-Client Architecture
Each client's configuration, templates, and content are isolated from every other client's, by construction. Adding a new client is a configuration addition, not a rebuild — the same deployment now serves the agency's full roster.

Deployment
A production-ready, containerized Docker image built on TypeScript, NestJS, Redis, and PostgreSQL, with the video render engine packaged as a separate container from the main application — allowing the render engine to restart independently on template changes, with no downtime for the API, the campaign queue, or document rendering.

The Outcome

The platform went into production use as a replacement for the agency's manual workflow, covering both social asset production and corporate document rendering across the full client roster.

The tangible results:

Production now runs on a defined campaign lifecycle instead of ad hoc requests — every piece of content has a visible status, for every client, at all times.
Brand compliance is enforced by the rendering system itself, removing the dependency on any individual designer remembering the current guidelines.
Corporate documents and social assets share the same reliable production pipeline, with the same status discipline applied to both.
Client work is structurally isolated — the agency can onboard additional clients without touching the assets, templates, or data of any existing one.
The render engine can be updated and restarted independently of the rest of the platform, so a template change no longer risks disrupting document rendering or the campaign queue.

The agency's production capacity is no longer tied one-to-one to headcount. Client growth is now a configuration problem, not a staffing problem.

The Principle Behind the Work

Production capacity is not lost because a team lacks skill or effort. It's lost because the process behind that effort was never designed — it accumulated, one workaround at a time, until it could no longer absorb growth without absorbing more people alongside it.

Rendering, branding, and document production are not creative afterthoughts sitting downstream of the real work. They are the throughput of the business. When they run on an engineered process, they scale with client count. When they run on individual habit, they cap it.

This engagement is a direct application of that principle: map the production lifecycle, engineer the system behind it, deploy it as infrastructure the agency owns.

This case study has been anonymised. Client and product names have been removed. All described functionality reflects delivered, production-ready work.