In private testing · People who publish short video

One long video,
fifteen vertical clips

The tedious part of short video is not the editing, it is deciding where a clip starts and ends, then reframing a widescreen shot so the speaker is not half out of frame, then writing a title for every single one. This does those three things and hands back finished files.

1080x1920: h264 and aac, ready to uploadOn device: nothing is uploaded to a serverDesktop and Android: same tool, two shells
What it does

The parts that
actually run.

Written in the present tense because each of these has been used. Anything not built yet is in the last paragraph on this page instead.

01

Cuts where the video actually changes

Clip boundaries follow scene changes rather than a fixed length, so a clip does not start halfway through a sentence or end on a cutaway.

02

Keeps the speaker in frame

A widescreen shot cropped to vertical loses most of its width. The crop follows the face, and it moves slowly, because a frame that snaps around is worse than a frame that is slightly off.

03

Writes the upload text per clip

A title under 100 characters and ten to fourteen tags for each clip, written from that clip's own transcript, not from the video's description.

04

Trims and splits by hand when you disagree

The automatic cut is a starting point. You can trim either end or cut a chunk out of the middle, and the removed part is shown as a gap rather than silently disappearing.

05

Exports straight to the phone gallery

On Android the finished file lands in the gallery, so the upload app finds it with no file manager involved. Export keeps running if you leave the app.

How it is built

The decisions,
and why.

Every one of these was a fork in the road where the other option was easier. This is the reasoning, so you can disagree with it.

No server, on purpose

Video is heavy and uploads are slow. Everything runs on the machine you already have, which is also why the tool has no running cost and no queue.

Encoding speed is a physics limit, not a to-do

Measured on a Snapdragon 845 phone, encoding runs about 1.8 times realtime, so a 60 second clip takes roughly 35 seconds. A faster phone is faster. No amount of code makes that number a promise.

The model reads the transcript, it does not guess

Titles come from what is said inside that specific clip. On a test run, a 0.58 second final clip was titled as a one second glimpse, which is only possible if the text was actually read.

Said plainly

Nobody pays for this yet and it has no signup. It has been run end to end on a real 14 minute talk on a real phone, and it produced 15 clips with no failed step, but a tool that has worked for one person is not a product. If it becomes one, it will say so here first.

Genuinely useful. It decides whether this gets finished.

The rest of what
gets built here.

Three products are live and two of those take money. The service side builds the same kind of thing, scoped to one business.