Case Study
A video engine that cut
production from days to minutes.
A programmatic video studio built at GoInvo that treats video frames as React components, replacing a manual production pipeline with an automated system that renders multi-platform content from structured data.
The Problem
At GoInvo, we produce outreach videos for healthcare and civic design projects: explainers, pitch decks, data-driven narratives. The process was entirely manual. Open Premiere or After Effects, lay out text, animate charts by hand, export, repeat. Every new video meant starting from scratch.
The bottleneck wasn't creative direction. It was production. A two-minute video with six scenes, a few charts, and some text animation could take a full day. Change the data? Re-render. New client branding? Rebuild the project. Need it in square for Instagram and vertical for TikTok? Do it again twice.
The people who needed to create these videos (designers, researchers, project leads) weren't video editors. They had the content and the stories, but the tooling stood between them and a finished video.
The bottleneck wasn't creative direction. It was production.
Research
Before building anything, I surveyed the landscape of video production tools to understand what existed and where the gaps were.
Traditional editors
Premiere, After EffectsPowerful but manual. Every video starts from scratch. Not programmable for batch generation.
Template platforms
Canva, Lumen5Fast for non-technical users, but locked into their template library, animation vocabulary, and export options. Low output ceiling.
AI-native video
jitter.videoDesign-driven and motion-first, with AI auto-animation from Figma imports. Great for one-off motion design, but no programmatic API or batch pipeline: each video still needs manual setup, so it doesn't solve the recurring-content throughput problem.
Code-based video
RemotionThe right abstraction. Frames as React components. Full web platform power. No visual editor, but that enables the automation we needed.
Remotion reframes video as a React rendering problem. Each frame is a React component rendered via headless Chrome and FFmpeg. Scenes are components, themes are data, aspect ratios are free, and rendering is automated. The tradeoff is no visual editor, but that's exactly what enables the automation we needed.
Choosing the Visual Style
Most video generation tools default to the same look: rounded corners, blue-purple gradients, geometric sans-serif type. These choices signal “consumer software” to the brain's rapid categorization circuits before the user reads a single label. Pre-attentive visual processing classifies an interface in under 200ms based on shape language, color temperature, and typographic weight. I wanted Rendomat to register as a creative environment in that first blink.
The direction: editorial. Sharp corners (no border-radius) shift the visual register from “software product” to “design tool.” Warm tones at hue 30 (beige, amber) tap into the brain's association between warm color temperature and materiality (paper, wood, leather) rather than the cool-blue digital associations that dominate SaaS UI. Instrument Serif for titles creates a typographic hierarchy that the eye parses in a single fixation, because serifs provide stronger word-shape differentiation than geometric sans-serifs at display sizes.
Why sharp corners everywhere?
No border-radius. It immediately shifts the tone from "software product" to "design tool." It signals intentionality.
Why warm, muted tones?
Background at hue 30 (warm beige), amber/gold accent at hue 38. The palette evokes paper and material surfaces, which primes the brain for creative work rather than data entry.
Why serif typography?
Instrument Serif for titles gives weight and character. Combined with uppercase tracked captions for labels, it creates a typographic hierarchy that feels considered.
Why minimal ornamentation?
No gradients, decorative shadows, or illustrations. The content (videos, timeline, scene data) is the interface. Inspired by VSCO, print magazines, and film photography.
Scenes are components. Themes are data. Aspect ratios are free.
The same composition renders at 16:9, 1:1, or 9:16 by changing two numbers. One render pass produces content for every platform.
Solving the Bottlenecks
The engine is built around three bottlenecks that made video production painful: composition time, render time, and platform fragmentation.
Composition: scenes as React components
In Premiere, every video starts as an empty timeline. In Rendomat, you pick scene types (text, chart, image grid, equation) and fill in the data. Each scene is a React component with typed props. Adding a new scene type means writing a new component, not learning a plugin API.
That's what makes batch production possible. Changing the data or swapping the brand theme triggers a re-render while the underlying structure stays intact.
Render time: smart caching
A seven-scene video takes 2-3 minutes to render from scratch. But most edits touch one or two scenes. The caching system hashes each scene's data with SHA256 and only re-renders scenes whose hash changed. FFmpeg stitches cached and fresh clips together.
Result: editing one scene drops render time to under a minute. Re-exporting with no changes takes seconds. Transitions render as separate clips too, so swapping a transition doesn't invalidate the scenes on either side.
Platform fragmentation: render once, export everywhere
YouTube needs 16:9. Instagram feed needs 1:1. TikTok needs 9:16. In a traditional editor, that's three separate projects. In Rendomat, the same composition renders at any aspect ratio by changing two numbers. One video, three exports.
For projects needing post-production polish, Rendomat also exports full After Effects projects. A JSON manifest describes every layer, keyframe, and easing curve, and an ExtendScript importer reconstructs the composition. The tool handles the 90% case. When a client needs something custom, the project transfers without starting over.
Cloud Rendering
Local rendering ties up the machine. A seven-scene video can block the Node.js process for two to three minutes, and there's no way to serve multiple users from a single instance. To scale Rendomat beyond a single-operator tool, I moved the render pipeline to AWS Lambda using Remotion's serverless infrastructure.
The server exposes a /api/render/capabilities endpoint that reports whether Lambda is configured. When it is, the UI offers cloud rendering alongside the local option. Clicking “Render in Cloud” triggers an authenticated request that validates the video, checks the user's credit balance, and dispatches the full scene and transition composition to a Lambda function. Progress streams back to the client via Server-Sent Events, polling Remotion's getRenderProgress API every two seconds. The finished video lands in an S3 bucket, and the output URL is stored on the video record.
Remotion Lambda
Render jobs dispatch to AWS Lambda with 40 frames per invocation. IAM policies scoped to remotionlambda-* S3 buckets and remotion-render-* functions.
Dual Render Mode
Runtime capability detection lets the UI toggle between local and cloud rendering. Local stays available for development; cloud handles production loads.
Credit Billing
Stripe checkout sessions for credit packages (5/20/50 credits) with webhook fulfillment, idempotency guards, and per-render credit deduction tied to authenticated users.
From Outreach to Recurring Content
The original scope was one-off outreach videos: a pitch to a potential partner, an explainer for a new project, a data visualization for a report.
Once the scene and caching systems were working, the pivot to recurring social media content was obvious. The engine already supported structured data in and video out, multi-format export, brand theming, and AI content generation via Claude for scene content, chart data, and copy improvement.
A studio that previously spent a day on one video can now produce a batch of platform-specific clips from the same source material, with consistent branding and professional motion design.
Treating frames as a rendering problem, not an editing problem.
What I’d Do Differently
I learned to prototype the surface people touch before the system underneath.
I built the rendering pipeline first because it was the hardest technical problem. But the timeline editor was what revealed the real UX requirements. Features that seemed obvious in the data model turned out to be wrong once I could see and interact with them. I now build the interface people will actually use before investing in the infrastructure behind it.
I learned where the real bottleneck was (and it kept moving).
First the bottleneck was render speed, so I built the caching system. Then it was the blocked event loop, so I moved rendering to a worker. Then it was the inability to preview transitions without a full render, so I built the preview pipeline. Each fix shifted the constraint somewhere new. I got better at anticipating which constraint would emerge next instead of reacting after the fact.
Built with