Should I vibe code
Browser video editing, recording, subtitles, avatars, and collaboration
Your cut lands on the nearest keyframe, not where you clicked. Closing that gap is most of what an editor costs.
?
Their verdict, the Lite price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Nothing here can hurt anyone but you, which is why the numbers are as low as they are — and it is still not worth building, because the demo and the product are separated by about a year. A timeline that plays clips is a satisfying afternoon. A timeline where the cut lands on the frame you clicked is a different piece of software: browsers seek to keyframes, not frames, so your trims arrive up to a couple of seconds away from where you meant them and the fix is decoding and re-encoding around the edit. Then there is the export, which either happens in the tab through ffmpeg.wasm — no hardware acceleration, a memory ceiling that a ten-minute 4K clip walks straight through — or on a server you now run, pay egress for, and watch die at 94%. The honest version of this build is not an editor at all. It is a script: ffmpeg doing the same four operations to every file you shoot, driven from a config, run on your own machine where the encoder is in silicon. That version is worth writing this weekend. The one with a timeline in it is worth $24 a month.
What actually breaks
not "if". the specific failures.
- Seeking, which in a browser is keyframe-accurate rather than frame-accurate, so every trim lands somewhere near where you clicked
- ffmpeg.wasm on anything longer than a few minutes, which exhausts the tab's memory and takes the unsaved project with it
- Export without hardware acceleration, which turns a two-minute render into twenty and cannot be backgrounded because the tab has to stay open
- Audio drift when you concatenate clips shot at different framerates or sample rates — a slow desync nobody notices until minute four
- Whisper over silence, which invents a confident sentence during a pause and then burns it into the subtitle track
- Burned-in subtitles generally, where fixing a typo means a full re-render rather than an edit
- Undo across a timeline, which is a genuine data-structure problem and the first thing a generated editor gets wrong
- Codec and autoplay behaviour, which differs per browser, changes with releases, and is nobody's fault in a way you can fix
Is that you?
the verdict is a default, not a law
- It is a script rather than an editor — ffmpeg performing the same operations on every file you shoot
- The edits are mechanical: trim to markers, burn subtitles, resize for three aspect ratios, top and tail with a bumper
- Rendering happens on your own machine, where the hardware encoder already exists, not in a tab
- You are the only user and a failed render costs you a coffee and a retry
- Anyone else needs to open the timeline, because the timeline is the product and it is the year of work
- You are accepting other people's footage onto a server you run, which is a storage bill and a moderation question at once
- You need comments, versions or shared projects, which is a second product bolted onto the first
- The output ships to a deadline and there is no fallback for the render that dies at 94%
- You were hoping to match the AI features — avatars, translation, one-click clipping — which are model bills, not code
If you build it anyway
the checklist, then the prompt that enforces it
- Decide first whether you are building a script or an editor. The script is a weekend and genuinely useful; the editor is a year and you already know how it ends.
- Do all real encoding server-side or in a native process with hardware acceleration. ffmpeg.wasm is for previews and short clips, not for delivery.
- Never mutate source footage. Every operation writes a new file and the original stays untouched — the undo story you actually need is the filesystem.
- Keep the project file as plain JSON referencing source paths and timestamps, so a broken editor never means a broken project.
- Ship subtitles as a sidecar .srt or .vtt by default. Burn them in only at the final export, when the text has been read by a human.
- Normalise framerate and sample rate on ingest rather than at concatenation, which is where drift comes from and where it is hardest to see.
- Show render progress from ffmpeg's own output and make jobs resumable. A render that cannot be resumed will fail at 94% on the day it matters.
I want browser-style video editing for my own footage. Before you build a
timeline, talk me out of it — then build the smallest thing that does the job,
in this order, and push back if I ask for the fun part first.
1. Start by asking what edits I actually repeat. If they are trims, subtitles,
resizes and a bumper, build a config-driven ffmpeg script and tell me the
timeline is not needed. Only build a UI if I insist after that.
2. Source files are read-only. Every operation writes a new output; nothing
ever overwrites the footage I shot. Prove it before adding features.
3. The project is a JSON file of source paths, in and out points, and effects.
A broken app must never mean a broken project.
4. Real encoding runs in a native ffmpeg process with hardware acceleration,
not ffmpeg.wasm. Use wasm only for scrubbing previews, and tell me its
memory ceiling up front.
5. Explain that browser seeking is keyframe-accurate. If I need frame-accurate
cuts, say that this requires decoding around the edit point and show me the
cost before I design around precision I do not have.
6. Normalise framerate and sample rate on ingest. Concatenating mixed sources
without that is where audio drift comes from and it is invisible until late.
7. Subtitles are a sidecar file by default. Burning in happens once, at final
export, after a human has read the text — Whisper invents sentences over
silence and I need a chance to catch it.
8. Render jobs are resumable and report real progress parsed from ffmpeg. No
spinner that lies.
9. Out of scope unless I ask: collaboration, comments, cloud storage, accounts,
uploads from anyone but me, avatars and translation.
10. When it works, tell me which parts of the paid product I did not build, so
I can price my weekends against $24 a month.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
As soon as you want a timeline, a second person, or the AI features. $24 a month buys frame-accurate editing, a render farm you do not operate, and subtitle and translation models you would otherwise be metering yourself — and the browser editor is the single most expensive thing in this category to build well. Keep your own script for the mechanical work you do every week; that part is genuinely better homemade.
$24/mo is cheaper than your weekend.
Because the source footage is never modified and the project is a JSON file, there is nothing to migrate — abandoning your own tool costs you the edit decisions, not the video. Keep exports and the project files in the same directory as the source clips and name them consistently, and moving to a real editor is a matter of re-cutting, not recovering.
Open-source browser video editor positioned as a CapCut alternative — the closest thing to a working answer to "how hard can a web timeline be".
FFmpeg compiled to WebAssembly; the engine every in-browser editor reaches for, and the memory ceiling every one of them eventually hits.
Open-source non-linear video editor.
Questions
Why is a video timeline so much harder than it looks?
Because playback and editing want opposite things from a video file. Compressed video is stored as occasional full frames with differences in between, which makes playing it cheap and jumping to an arbitrary frame expensive. Every timeline feature people take for granted — scrubbing, frame-stepping, a cut exactly here — is work to hide that fact. In a browser you have the least control over decoding of anywhere, which is why the web editors that are any good are years old.
What does the good version of this actually look like?
A folder, a YAML file and ffmpeg. You describe what happens to a clip — trim from these markers, add these subtitles, output at 9:16 and 16:9 and 1:1, prepend the intro — and run it over everything you shot that week. It has no UI, it is a hundred lines, it runs at full hardware speed, and for repetitive content it beats the paid tools on the only axis that matters, which is how long it takes you.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
A browser video editor is a weekend right up until Export. That button is the entire product.
You can generate the shots in an afternoon. What the subscription buys is permission to publish them.
A highlight extractor's whole job is removing context. The guest in the clip will have a different word for it.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice