Creative Automation at Scale: From SVG Templates to Hundreds of Reels

A single client launch can need a dozen feed posts, a handful of stories, highlight covers, a flyer, and two or three reels. Do that across 30+ platforms and you are either drowning a designer or you are automating. We automated. One generator, fed a data file, produces a full campaign set — posts, carousels, covers, and video — every asset on-brand because the brand lives in code, not in someone's afternoon. This is how the pipeline is built.

The usual objection is that automation belongs to engineering and creative is supposed to be hand-made. That is true right up until your brand rules are strict enough to write down. Ours are: black-and-white minimalism, a fixed type stack, an ink scale, hairline rules, no color accent. Once a rule is that precise, it is not a taste call anymore — it is a constant you can encode. And anything you can encode, you can repeat a hundred times without a human in the loop.

When automation belongs in creative

Code automation is obvious; creative automation makes people flinch. The fear is that a generator produces soulless, samey output. It does — if the rules are vague. The whole game is the inverse: the stricter and more legible your brand system, the better a candidate it is for automation, because there are fewer free variables for a machine to get wrong.

A loose brand — pick any font that feels nice, any photo that vibes, accent colors by mood — cannot be automated, because there is no function to write. A tight brand can. When the headline is always Space Grotesk, the body is always Inter, the eyebrow is always uppercase mono, and the palette is three shades of ink on white, the design is a template with holes in it. Fill the holes from data and you have a finished asset. The discipline that makes a brand recognizable is the same discipline that makes it scriptable.

So the line we draw is not 'creative vs. code'. It is 'decided vs. undecided'. The decided parts — layout grid, type, palette, the shape language — get encoded once. The undecided parts — the headline, the offer, the photo, the order of slides — stay in a data file a human edits. The generator is just the glue that turns decided rules plus undecided data into a deliverable.

Data-driven SVG templates as the source of truth

Every asset starts as an SVG template, because SVG is text. Text is the right substrate for the same reason it is right for the rest of our stack: it is tiny, resolution-independent, generated by string concatenation, and reviewable in a pull request like any other code. A template is a function — campaign data in, finished SVG markup out — never a static file someone duplicates and edits by hand.

The campaign itself is one JSON (or TypeScript) file. It holds the variable content: brand tokens, the list of posts, each post's headline and subhead, which template to use, any image path. The generator iterates that array, and for each entry calls the matching template function. Add a post to the array, get a post in the output folder. Nothing is positioned by hand twice.

Two properties matter here. First, a template can only draw with brand tokens — the headline font is brand.head, never an arbitrary string — so a post physically cannot ship off-brand. Second, because the input is data, the output is reproducible: the same campaign file always produces the same set. That is the same determinism principle behind our generative cover-art pipeline, applied to whole campaigns instead of single images.

Rendering: headless Chrome, SVG to PNG

SVG is the master format, but Instagram and WhatsApp want raster — an actual PNG at a fixed size. So every SVG string goes through a render step. For pure SVG with no web fonts to resolve, a rasterizer handles it directly; when the template uses real web fonts or CSS layout, we render through headless Chrome with puppeteer-core and screenshot the node at a pinned viewport. Same render path we reuse across the whole studio.

One browser instance, looped over the campaign array, writes the whole set to a folder. Carousels are the same idea with the array shape changed: instead of one SVG per post, a post owns an ordered list of slide SVGs, and the renderer names them slide-1, slide-2, and so on. Highlight covers, flyers, and OG cards are all just more templates pointed at the same render loop. The pinned Chrome channel matters — a floating browser version can shift anti-aliasing and break the 'same data, same PNG' contract.

Motion: ffmpeg reels and Remotion video

Stills are half the brief. The other half is video — reels and stories that move. We use two motion paths depending on how much the video needs to think about its own data, and both reuse the still pipeline as their first stage.

ffmpeg for frame-sequenced reels

The simplest reel is a sequence of stills with timing, motion, and audio. We generate the frames the same way we generate posts — one SVG per frame, rendered deterministically to PNG — then hand the numbered sequence to ffmpeg, which stitches it into an MP4 at the target frame rate, scales to the vertical 1080x1920 reel canvas, and muxes a music bed. No editor, no timeline, no manual export.

The deterministic-frame approach is the unlock: because each frame is a pure function of frame index plus campaign data, the motion is repeatable and reviewable. Tweak the data, re-render the frames, re-stitch — the reel updates with zero manual editing. The frames are just the still pipeline run per timestep.

Remotion for data-driven video

When the video needs to react to its content — a product showreel where slide count, copy length, and pacing all depend on the data — frame-by-frame SVG gets awkward. That is where Remotion earns its place: video as React. Each frame is a component that reads the current frame number and the campaign props, and renders accordingly, so the same brand tokens and the same template logic that drive the stills now drive the motion. One source of truth, two output formats.

• Stills — data-driven SVG templates rendered to PNG through headless Chrome. Posts, carousels, covers, flyers, OG cards.
• Simple motion — deterministic SVG frames rendered to PNG, stitched by ffmpeg into reels with a music bed.
• Smart motion — Remotion, where each frame is a React component reading campaign props, for showreels whose pacing depends on the data.
• One brand layer — the same tokens and template logic feed every path, so a still and a reel from the same campaign are visibly siblings.

Encode the brand once. After that, a campaign is a data file, and a hundred assets is a single command.

— Studio principle

One generator, a full campaign set

Pulled together, the shape is simple. A campaign is one data file. A gen script reads it, runs each entry through its template, renders the stills, sequences the reel frames, and writes everything to a clearly-named output folder — posts in one subfolder, stories in another, covers in a third, video at the root. This is exactly how our launch kits get built: BP Couriers' Instagram puzzle, the highlight-cover sets, the weekly ad creative for The Language Cradle, the reels that ride on top. One operator, a data edit, a full set out.

The payoff is leverage. A studio of a few people cannot hand-design a dozen assets per launch across dozens of brands and still ship software. Encoding the brand collapses that work into an edit and a render. The creative decisions still belong to a human — the headline, the offer, the photo, the story arc across a carousel — but the production is mechanical, which is exactly where it should be. If you want the still-only version of this thinking, we wrote up the generative cover-art pipeline; the same backbone runs everything in our Supreme Suite launch tooling.

None of this replaces a designer's judgment about what makes a campaign land. It replaces the part where a person manually nudges the same headline into the same box for the ninetieth time. That part is not creative. It is data entry wearing a design tool's clothes — and it is exactly the part a generator should own.