TakeWrite — Motion Graphics Engine & Production App

The project

The problem

Data-driven motion graphics normally mean an animator hand-keyframing every element, for every video. That does not scale across dozens of guests, brands and topics. And even with the graphics done, an editor still burns hours scrubbing a two-hour recording for the moments worth keeping. The bottleneck was never the rendering. It was everything around it: deciding what stays, planning the camera, choosing a look, approving any of it. All of that lived in someone's head and a pile of message threads.

The build

The engine renders every frame from code instead of hand-keying it. Cinematic push-ins, cut-out compositing over live footage, self-drawing charts, captions synced to word-level timing. Because it is code and not a model generating video, nothing on screen can hallucinate a number, and a render costs compute rather than a per-second fee. Twenty-nine visual worlds are built and switchable, each a real render with its own preview clip, not a recolour of one template. The web app is what makes the engine operable without me in the room. Five stages, each one a gate: upload, edit plan, rough cut, graphics, final. The engine proposes, a human approves, never the other way around. Two details carry most of the weight. It reads both camera mics to work out who is speaking and plans the shot changes from that, with no transcription API and no per-minute cost. And the rough cut comes back as a video you can watch, because nobody approves an edit by reading a list of timestamps.

The outcome

A 33-minute two-camera recording comes back as a proposed 17-minute cut across 26 reviewable sections, each carrying the reason it was kept or trimmed. Then as a rough cut you can watch. Then as a graphics pass where every beat says why it was placed. The editor still finishes in Premiere, but with a cut list and word-level timestamps instead of hours of scrubbing. Every version is logged, gated and reversible.

33:01 → 17:39Raw recording to a proposed cut

26Sections you can keep, tighten or cut

5Approval gates before anything renders

How it runs

01 · Start the episode
The client creates the episode and drops in both camera files, the intro voiceover and any guest photos. Everything downstream keys off this one record, so there is a single source of truth per episode instead of a thread full of file links.
02 · Review the plan
The engine proposes what stays and what goes, section by section, with the reason attached to each one. 33:01 of raw comes back as a proposed 17:39 across 26 sections. Every row can be kept, tightened or cut, and nothing moves on until it is approved.
03 · Watch the rough cut
The approved plan gets assembled, both camera mics are read to work out who is speaking, and the shot changes are planned from that. It comes back as a video you can actually watch and judge, with no graphics on it yet, so the cut and the camera work get signed off on their own.
04 · Review the graphics
Every graphic beat arrives with the reason it was placed and the orientation it renders in, and any of it can be swapped per beat. The visual world for the episode is chosen here from the built library, each one previewable before you commit.
05 · Final
Only once the cut and the graphics are both signed off does anything expensive render. The engine stops at awaiting approval by design and cannot advance itself past a gate.