Clippa

The problem

Clipping software is built for adults who already know what a codec is. A nine-year-old in my house wanted to cut funny moments out of long stream recordings and kept getting stuck: timelines that need frame-accurate dragging, export dialogs asking for a bitrate, and cloud tools that want an account and an upload before they will do anything. The real problem was not the cutting. It was that finding the good moment in a four-hour recording is the boring part, and every tool made you scrub for it by hand.

There was a second constraint I cared about more. A kid's tool should not quietly ship a family's home videos to somebody's server, and it should not stop working the day a subscription lapses.

What it does

1. Drop in a recording or an existing clip — the app probes the file and picks a playback path per file: play it natively when it can, remux when that is enough, and fall back to a 720p proxy only when it has to.Scrubbing a four-hour file has to feel instant or a kid gives up.
2. Find moments for me — scans the audio for loudness spikes, scores them with a peak picker, and hands back candidate moments as cards you can tap.
3. Trim by feel — a magnifier timeline over a fine strip, so you can be roughly right quickly instead of exactly right slowly.
4. Make it yours — add your own text, import your own sounds, drop a watermark on and drag it where you want it.No bundled sound library and no auto-captions, on purpose. The sounds are the kid's own.
5. Save the clip — renders to MP4 in Wide or Phone (9:16, drag to aim the crop) and writes it straight to the Videos folder.

The AI part, and why it is optional

With no API key, moment-finding still works. It is a loudness scan with a z-score peak picker, entirely offline. Add a key in the grown-up settings and a second stage turns on: short audio slices around each candidate are transcribed locally with a bundled whisper.cpp build, and only those text snippets go to Claude, which ranks the candidates and writes a short kid-friendly title for each. The video itself never leaves the machine.

The part I am most pleased with is how little the model is trusted. It answers into a schema, and the timings it returns are then clamped in code to within ten seconds of the candidate the audio scan actually found, no matter what it said. If it refuses, times out, hits the token ceiling, or returns something unparseable, the call returns null and the app falls back silently to the offline result. The user never sees an error about a feature they did not ask for. That invariant is written down as a project rule: the no-key path must always work end to end, and must never regress.

The key itself is encrypted at rest with Electron's safeStorage, lives in exactly one module, and is never passed to the renderer.

Engineering decisions worth naming

1. The renderer never learns a file path. Media is addressed by an opaque token over a custom clippa://media/<token> protocol. Every IPC message is runtime-validated with Zod in both directions against one shared schema file, and senders are checked too.
2. FFmpeg, ffprobe and whisper are always spawned with argv arrays, never through a shell. That closes the obvious injection door in a tool whose whole job is accepting arbitrary user filenames.
3. Preview and export share one geometry module and one text renderer. They are never forked, because the moment they diverge, what you saw stops being what you got.
4. Timestamps are normalized explicitly after every trim rather than trusting a seek flag to zero the clock. That is the bug that silently produces clips with a black first second, and it only appears on certain sources.
5. Progress bars are never faked. Phases that cannot be measured show indeterminate UI instead of an invented percentage.

How it is verified

The suite runs unit tests and real export checks against a fixture set chosen for the places video pipelines actually break: HDR PQ, MKV/Opus, MPEG-2 transport streams, variable frame rate, 90-degree rotated, odd dimensions, square and tall, non-zero and shifted start timestamps, a file with no audio track, and a filename mixing Japanese, Cyrillic and a #.

On top of that there is an end-to-end self-test that drives the real renderer — open, probe, play, seek, thumbnails, decorate, export, cancel, find-moments — and exits non-zero on any failure. It runs against the packaged executable, not just the dev build, so "works on my machine" is not the standard. One of its assertions is a security check: it searches the IPC response for anything shaped like a Windows drive path and fails if a raw path ever leaked to the renderer.

The rule I held myself to: a milestone is only done when unit tests are green, the fixture exports verify, and the packaged smoke test passes.

Directing the AI, not just prompting it

This was built quickly with AI-assisted development, which is exactly why it carries a short AGENTS.md of durable rules at the repo root. Every constraint above lives in it as one line: no shell spawns, both-direction IPC validation, no raw paths in the renderer, never fork preview and export, the fallback must never regress, never fabricate progress. The value is not documentation. It is that an agent working on the tenth milestone cannot quietly undo a decision made in the second one, and that a passing test suite is what gets to call something finished.

Twelve milestone commits, then six packaged releases from 0.1.0 to 0.1.5 as it got real use and the rough edges came back.

The story · STAR

Built with

Status & honest limitations

Self-directed project, built with AI-assisted development.

Design note

The interface is deliberately loud and round: big targets, plain-language labels, confetti when a clip saves. Anything that looks irreversible is phrased as a question a child can answer. The hardest design constraint was not visual. It was refusing features that would have made the app more impressive to an adult and less finishable by a kid. No auto-captions, no sound library, no bitrate field.