Your README already contains the script. Here's the approach that turns it into a watchable 60-second demo from editable scenes — and the place it quietly falls apart.
Your README already contains the script. The install command, the quickstart, the one API call that shows what the project does — that's the outline of a good 60-second demo. The hard part was never the words. It was turning them into something watchable without booking an editor or fighting a timeline for an afternoon.
Here's the approach that works, and the place it quietly falls apart.
Most “make a video from text” tools start from a blank prompt, so you get generic filler — a smooth voice saying nothing your project actually does. A README is the opposite: it's specific. It names the real command, the real flag, the real function. If you ground the script in it, the video says what the repo says, not what a model guessed.
That grounding is the whole trick. Point the generator at the README (or paste it in), and the script should come back with your actual install command, your actual import, your actual quickstart — not “simply install the dependencies and get started in seconds.” When it drifts into that kind of language, that's your signal the grounding isn't working and you're back to filler.
Sixty seconds, roughly four beats:
The reason to render these as components rather than screen-record them is boring but important: a screen recording of a terminal is unreadable on a phone, and it's frozen the moment your CLI changes. A typed-out terminal component and a code card are legible at 9:16 and editable after the fact.
Here's the difference that matters six weeks from now, when you rename a flag or bump a version. If the demo was a recording, it's stale and you re-record. If it was built from editable scenes, you open the one scene with the old command, fix the text, and re-render. The video tracks the repo instead of rotting away from it.
That's also why “one afternoon” collapses to “ten minutes.” You're not performing a take; you're editing a document that happens to render as video.
Two failure modes, stated plainly.
The first: a thin README makes a thin video. If your README is three sentences and a badge, there's nothing to ground a script in, and no tool fixes that — you'll get something generic because the source was generic. Write the README first; the video is downstream of it.
The second: the demo is not a substitute for the real thing. A code card is the right way to show an API call, but if your project's whole value is an interactive UI, a component-built explainer only takes you so far — at some point you want a real screen recording of the actual product, and that's a different tool. Be honest with yourself about which kind of project you have.
This space is also getting crowded fast — there are now several tools that read a repo and spit out a video (a couple are genuinely good). The differentiator worth caring about isn't “can it generate a video,” it's “can I edit the fourth scene without redoing the other three.” That's the question to ask any of them.
If you want to try the editable-scenes version: point the studio at your README, let it draft the four-beat script, then open each scene and make it true — fix the command, swap the snippet, tighten the hook. Render when it's right, publish to your channel. The README did most of the work; you're just making sure the video didn't round off the details that make your project yours.
Get one practical MCP-video tip when we publish the next post — no more than that.
Point your agent at a video pipeline that speaks MCP and make one small thing. Free founding-creator pilot — your keys, no watermarks.
Create your studio — free pilot