I build software. I had never opened a video editor in my life — no timelines, no keyframes, no idea what "ducking" meant. But I needed a polished, ~2 minute explainer video for a document-intelligence product, and the quotes for "a professional corporate demo video" were not the kind of number you spend on a side project.
So I did the thing engineers do: I treated the video as a codebase.
This is the honest write-up — what I built, what genuinely worked, what fought me the whole way, and what I’d do differently. If you’re a developer staring down the same problem, I hope it saves you a few weekends.
The core decision: video as code
The single best decision I made was choosing Remotion — a framework that lets you write videos as React components. Frames are just functions of time. A scene is a component. Animation is interpolation between frame numbers.
For a developer with zero video-editing instinct, this was the whole game. I didn’t have to learn a designer’s tool; I got to stay in the tool I already think in:
- ›The entire video lives in one
.tsxfile with a component per scene. - ›Every change is a git diff. I could see exactly what moved and revert when I broke something.
- ›It’s reproducible —
npm run renderand the same video comes out every time. - ›Timing is literal numbers: "this badge appears at frame 235" is a line of code, not a thing I drag with a mouse and eyeball.
The final piece was ~138 seconds, 8 scenes, 1920×1080 at 30fps. None of it required me to develop an editor’s muscle memory. It required me to write code, which I already knew how to do.
How I actually worked: a writers’ room of agents
I drove the whole project through Claude Code, and the thing that made it manageable was splitting the work into specialized agents, each with a narrow job and a short instruction file:
- ›a script-writer for voiceover copy and on-screen text,
- ›a scene-designer for the React/Remotion components and animations,
- ›a timing-coordinator for frame timing and sync,
- ›a visual-stylist for color, type, and "does this feel polished",
- ›an audio-engineer for music levels and the text-to-speech voice,
- ›an asset-manager for the video clips and images,
- ›a render-engineer for actually exporting the thing.
This mirrors how real video teams are organized — and it turns out the separation of concerns matters for the same reason it matters in software. When I asked for "make the transitions snappier," the visual concern didn’t accidentally rewrite my script. When I asked to "trim two seconds from scene 3," the timing logic changed without anyone touching the colors. Narrow agents kept changes localized, exactly like well-bounded modules do.
The one architectural rule that saved me: a single source of truth
Early on I learned the hard way that a video has two things that must never drift apart: what is said and when it’s said.
So I made one file the source of truth for both. A generate-voiceover.mjs script holds the script text and the timing for every scene. Running it does two things at once: it generates the voiceover audio (via Azure’s neural text-to-speech) and it writes out a timing file that the video imports. That generated timing file is marked never hand-edit — because the moment you edit the derived artifact instead of the source, your audio and your captions silently disagree and you spend an evening hunting a "bug" that’s really just two files telling different stories.
If I gave one piece of advice to my past self, it’s this: decide what your source of truth is before you write a single scene, and make everything else a build artifact of it.
What went right
Treating the script as the foundation, not the decoration. I wrote and rewrote the narration first, before animating anything. I even pulled from real research on document-management pain points to make the opening land ("Documents and more documents. Search after search. Still hoping you’ve guessed the right words…") instead of the generic "every business handles documents" line I started with. Locking the words early meant the visuals had something true to serve.
Cutting scope by cutting scenes. I started with 10 scenes and ended with 8. I deleted a feature-overview scene that added nothing and merged two thin scenes (the AI-chat and the verifiable-answers bits) into one. Every scene I cut made the video tighter and the whole project less to maintain. Killing your darlings is as healthy in video as it is in code.
Directing the viewer’s eye through dense UI. My product screens are busy. I considered a Ken Burns slow-zoom and rejected it — it looked cheap. Instead I built a spotlight effect: a glowing ring around the active area plus a vignette that dims everything else, moving in sequence (search bar → results list → highlighted text). That one technique did more for perceived professionalism than any color change.
Coordinate-driven annotations. Because everything is code, I could position callouts precisely. I’d read pixel coordinates straight out of Remotion Studio and tell the scene, "draw a ‘Verify Citation’ box at (1050, 500) with arrows to these three points." No dragging, no guessing — exact, repeatable placement.
What fought me the whole way
Audio sync is genuinely hard. This was my biggest time sink. The voiceover sounded natural when I played the raw clips, but stretched inside the video. Worse, I kept hearing lines repeat — "Your business already has the answers," three times in a row. I burned real hours convinced my code was looping the audio. Part of it was Remotion Studio’s own loop toggle being on; part of it was clips being shorter than their scene, so the video genuinely re-played them. The lesson: when audio misbehaves, separate "is this the player?" from "is this my composition?" before you debug anything.
Timing lives in two files, and that’s fragile. The scene start-frames in the video file and the matching timing in the generator have to stay in lockstep. They’re coupled by hand. Every time I retimed something I had to update both, and when I forgot, the last scene clipped mid-sentence (it did, more than once — one render literally cut off after "built specifically"). If I rebuilt this, I’d derive both from one place.
I do not have a designer’s eye, and color exposed that. I hated the purple the initial palette gave me, but "I don’t like purple" isn’t useful direction. I went through multiple palettes, built a side-by-side HTML preview to compare them, and eventually had to explicitly ask for the color scheme to be applied evenly across scenes with attention to cognitive load — because my first attempts had orange eyebrows in one scene and blue in another, green "chat" text bleeding where it didn’t belong. Consistency doesn’t happen by accident when you can’t feel it; you have to enforce it like a lint rule.
The product demo footage was the part code couldn’t save me on — more on that below.
The demo-footage detour (the thing I most want to warn you about)
The features only sell if people see them working. So I needed real screen recordings of the product: browse, keyword search, semantic search, hybrid, chat, verify.
My instinct, naturally, was to automate it. I wanted a script to drive a browser, perform each action perfectly, and capture clean footage — fully reproducible, like everything else. I went deep on this. I looked into running a real browser inside WSL, into browser-automation capture, the whole path.
It wasn’t worth it. Getting a headless/automated browser to render the app and produce a smooth, correctly-sized, nicely-paced screen capture turned into a rabbit hole that cost more than the footage was worth. In the end I just recorded my own actions against the running product, at the exact target resolution the scenes expected (1440×900), and dropped the clips into the project.
Manual recording took an afternoon. The automation attempt had already eaten more than that with nothing to show. This is the one place where my "automate everything" reflex was simply wrong, and I’d skip straight to recording next time.
What I’d do differently
Lock the script before animating.
I rewrote narration after building scenes more than once, and every rewrite rippled into timing, captions, and on-screen text. Words first, always.
Derive all timing from one source.
Two hand-synced files is one too many.
Record the demo by hand from day one.
Don’t romanticize automating the parts that are faster to just do.
Set palette rules up front.
Define which color means which feature before building, not after noticing the inconsistencies.
Budget more time for audio than you think.
TTS timing, ducking, and sync were the long pole — not the visuals.
Was it worth it?
Yes — unreservedly. I got a professional-looking explainer for the cost of my own time, I can re-render it any time the product changes, and the whole thing is version-controlled like the software it describes. As a developer, I never had to become a video editor. I just had to treat video like what it secretly is: a function of time, written in code.
If you’re an engineer who’s been quoted an eye-watering price for a demo video, you have more leverage than you think. The hard parts aren’t the ones you fear — and the one part you’d assume you can automate is the one you should just record yourself.
