We ship every week now. Our launch videos don't. So I built Cutroom.

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

AI changed how fast we ship. A feature that used to take a days to weeks now takes an afternoon, and release notes go out every week, sometimes every day.

The launch video didn't get any faster.

You still have to write a script, rebuild the screens, record a voice, time the words to the cuts, export a vertical version for X and LinkedIn, and add captions because most people scroll with the sound off. A freelancer charges hundreds of dollars for one. Doing it yourself costs a day or two. So most releases ship with a screenshot and a paragraph, and the feature that took real work gets a post nobody watches.

Cutroom is an agent that reads your codebase and makes the product video for you.

Point it at a repository and you get a launch video. Point it at a release, a tag or a range of commits, and you get a "what's new" video about only those features. Not your whole product again, just what changed.

It does the work a copywriter and a motion designer would do:

1. It reads the repo and writes a product brief: what the product does, who it's for, and which features matter. Each feature is linked to the file and line that proves it.
2. It picks a structure (launch, tutorial, explainer, teaser, feature drop) and a visual style.
3. It writes the script, scene by scene.
4. It checks every claim in that script against the code.
5. It hands you a storyboard to edit and approve.
6. It renders the video with voiceover, music, captions and a thumbnail, in 16:9, 9:16, 1:1 and 4:5, all from the same storyboard.

Step 4 is the one I care about most. A product video is a promise. If it shows a button, people expect to find that button. If the script says "works offline" and nothing in the code backs that up, Cutroom flags the line before anything renders and suggests a version that is true. The agent doesn't get to make things up about your product.

It is also private by default. Cutroom runs on open-weight models (models whose weights you can download and run yourself) on your own machine. You can point it at a private repo, or at a client's codebase under NDA, and nothing leaves the laptop. That isn't a side feature; it's the reason this is an open-model project at all. More on that below.

Who would pay for it?

• Indie hackers and small dev-tool teams who ship weekly and want a video for every release, not just the big launch.
• DevRel and docs teams who need tutorials that match the current UI, not the one from three releases ago.
• Agencies that make launch videos for clients and can't upload client code to someone else's servers.

The plan is simple. The open-source app stays free to run yourself. A hosted version, around $29 a month, would add cloud rendering, premium voices and shared team presets. That is less than one freelance video, for a video every release.

Demo

]]

pnpm install
pnpm cutroom setup                 # downloads the Kokoro voice model once (~90 MB)
ollama pull gemma4:e4b             # default model; see docs/decisions/0003
pnpm cutroom make --repo ./path/to/app --preset launch-editorial --ratios 16:9,9:16 --privacy local

How I Built It

The open pieces

• Gemma, running locally through Ollama, does the thinking. It reads the code and writes the brief, the storyboard and the verdict on each claim.
• Kokoro does the voice. It's an open-weight text-to-speech model with 82 million parameters, Apache-2.0 licensed, and small enough to run on a laptop CPU. The voices in the editor (Heart, Bella, Nicole, Emma) are Kokoro voices running on my machine.
• Remotion renders the video. Remotion is a library that lets you make videos with React: every frame is a component, and the result is an MP4.
• ffmpeg handles the final loudness pass.

The one rule: the model never writes code

The obvious way to build this is to let the model write Remotion components directly. That's roughly what a frontier model would do. Small open models are not reliable at it: they write components that don't compile, or use props that don't exist.

So in Cutroom the model fills in a form instead.

Each scene type (a kinetic headline, a big number that rolls like an odometer, a row of feature cards, a real code excerpt from your repo, a terminal typing a command) has a schema written in Zod. The model chooses scenes and fills in their fields. A library of tested React scenes turns that into video. A scene looks like this:

{
  "block": "big-number",
  "props": {
    "label": "COMMITS GROUPED",
    "value": 42,
    "format": "integer",
    "line": "One release, *one page of notes*"
  },
  "narration": [{ "text": "Forty-two commits become one page." }]
}

If the JSON doesn't pass the schema, the errors go back to the model along with its last answer, and it tries again, up to three times. Word budgets are checked in code too: about 2.5 spoken words per second, so a 6 seconds scene gets 10 to 16 words, not 40.

That change moved the hard question from "can a small model write good React?" to "can a small model fill in a form correctly?". The second one it can do.

The pipeline

1. Ingest. Walk the repo, respect .gitignore, skip binaries and build output, and redact secrets before the model sees anything. It also collects every UI string (button labels, status names, messages) so the script can use the product's real words.
2. Brief. Large repos are summarised folder by folder, then combined. Every feature needs evidence, and that evidence is checked by plain code: the file exists, the lines exist, and the quoted excerpt is really in the file. Evidence that fails is dropped.
3. Storyboard. Gemma fills the scenes for the chosen structure and style.
4. Claim audit. Cheap, exact checks run first. A quoted button label must exist word for word in the code. A code excerpt must match the file. A number must appear in the evidence. Words that usually overclaim ("instantly", "globally", "always", "any") are flagged. Gemma then judges whatever is left, with the evidence in front of it.
5. Review. You edit and approve. Unsupported claims block approval unless you override them with a reason.
6. Voice. Each line of narration is generated as its own clip, so timing comes for free: a scene lasts as long as its narration needs.
7. Render. Every aspect ratio from one storyboard, with captions, a thumbnail and loudness normalised to −16 LUFS (the level YouTube and social feeds expect).

For releases, Cutroom reads the diff between two refs instead of the whole repo. Only added lines count as evidence for a "new" claim, so a feature-drop video can't call an old feature new.

Where the styles come from

Cutroom ships four visual styles: Studio (a dark stage with the app in a window), Editorial (warm paper, one big number per scene), Graphic (a white grid with one loud colour) and Cinematic (near-black and slow). These styles, and the craft rules behind them (pacing, word budgets, loudness and "show only what's real"), come from my open-source product-videos agent skill (MIT). Cutroom's engine, agent pipeline and app are new for this challenge, but a lot of the taste came from there.

What doesn't work yet

I'd rather say this here than have you find it.

• Cutroom shows your product through screenshots and code-derived scenes. It doesn't rebuild your screens as live, animated UI yet.
• Rendering on a laptop CPU is slow. 65 minutes for a 60-second video.
• A small model still writes a weak scene sometimes. That's why approval is a human step and not an option I hid.
• Remotion is free for individuals and companies of up to three people. Bigger companies need a Remotion company licence, and the hosted plan would have to account for that.

Why Does Open Innovation Matter?

The code a launch video is made from is the most secret code a team has. By definition, it's features nobody has seen yet.

Asking a team to upload unreleased code to a third-party API to make a marketing video is a hard sell. Asking an agency to do it with a client's code usually breaks a contract. That one fact decided most of this project.

• Because the code is private. In Local mode, Gemma and Kokoro run on your machine and nothing is uploaded. This is enforced in code, not in a promise: in Local mode, any provider that would make a network call refuses to start.
• Because "a video every release" has to be cheap. With paid APIs, every video comes with a token bill and a per-character voice bill. Locally, the extra cost of one more video is electricity. That's the difference between making videos for big launches only and making one for every release.
• Because it works offline. On a plane, on a bad connection, behind a company firewall.
• Because I can swap the model. Gemma today, a different open model tomorrow, and the same checks tell me whether the output got worse.

Where closed tools were better, honestly: ElevenLabs voices sound more natural than Kokoro, so Cutroom supports ElevenLabs as an optional upgrade, outside Local mode. And a frontier model writes punchier copy than a small local one. The schemas, word budgets and repair loop closed most of that gap. Not all of it.

My First User

I didn't get Cutroom in front of a real user inside the challenge window, so I'm saying that instead of inventing a testimonial. The first person I'm sending it to is a friend, because they needed to make a launch video for a fintech product. If you ship a product and want a launch video for your next release, try it and tell me where it breaks.

Prize Categories

• Best Use of Gemma: Gemma is the agent's brain. It writes the brief, the storyboard and the claim verdicts, running locally through Ollama.

Candidates: Best Use of Render (One click deploy), Best Use of a .tech Domain cutroom.tech, Best Use of ElevenLabs, Best Use of Temporal, Best Use of DigitalOcean (One click deploy).

---

Credits: Cutroom's visual styles and video-craft rules are adapted from my open-source product-videos skill (MIT). The engine, agent pipeline and app are new for this challenge.