Launch Video

Launch Video

The bar is a showreel: the piece a motion designer puts on their résumé to prove how good they are — dynamic, ambitious, scored to music, a real professional production and never a demo or prototype. Go all out. The repo supplies the story; the craft is yours. Nothing here is a template: if the piece could be re-skinned for any other project, it has failed.

Workflow

1. Find the story. Read the README, docs, benchmarks, and brand art. Done when you can state, each with a source: what it is in one line, how it works underneath (the audience is technical), and the proof worth landing. Flag any claim the repo cannot back instead of inventing its meaning.
2. Direct before you build. Choose one visual concept grown from what the project is (its metaphors, its brand art, its mechanism): a world with its own look, camera, and signature move, rather than a sequence of panels. Then commit to one familiar real-world analogy for the mechanism (building a city, running a kitchen, a heist) and map every step onto it: name each step in the analogy's vocabulary, and give each one the everyday props that explain it at a glance (a surveyor's tripod, stakes, cranes, an inspection stamp). Digestible beats clever: a viewer should get each step from references they already know, without reading a word. Write it as a shot list on a music timeline. Done when every shot names its camera move and the one moment in it a motion designer would be proud of. A shot whose description is "a card/panel/list appears" gets redesigned.
3. Build picture and score from one timing source. Every event time lives in one place that both the scenes and the soundtrack read, so hits land on hits. Synthesizing the music in code keeps that lock exact.
4. Review as a director. Render a draft, tile each shot into contact sheets, and get a fresh-eyes critique from a subagent that has not seen your plan. Then ask each shot the showreel question. Fix and re-render until every shot passes, not a sample.
5. Ship. Make the thumbnail (rules below), render the master (1080p60, high-quality H.264, 320k AAC), reveal it in Finder, and commit the project to the repo as a standalone package, with renders and generated audio ignored and a short README covering commands, the timing principle, and the claim sources and methodology kept outside the film.

Marketing, not a white paper

Lead with the product and a few memorable benefits. Keep methodology, sample sizes, missing-data allowances, benchmark caveats and source citations in the package README or linked report, not in the video or key art. Do not add fine print, asterisk footnotes, disclaimer blocks or defensive narration. If a claim needs narrowing to stay true, narrow the headline itself; never use tiny text to rescue a misleading headline. Review each frame for reading burden as well as visual quality.

Show, don't tell

Text is the last resort. Before any word goes on screen, find the picture that makes it unnecessary: an object that transforms, a world that changes, motion that performs the idea. Keep text only where nothing visual can carry it: the product's real commands, its name, and a claim that must be exact. The one exception is orientation: give each shot one header saying what is happening (it can be dynamic, like a live count that ticks with the action), or the best animation reads as random motion. When a draft leans on labels, captions, or subtitles to explain what is happening, redesign the shot instead of rewording the text.