How to build a browser video editor with Claude Code

Rule of thumb: if your users are editing their own short clips (a minute or two, on ordinary hardware) the browser handles it and you never see a compute bill, which makes owning the editor the obvious call. If your product processes long or high-resolution files, or has to render hundreds of videos without anyone present, rent the rendering, because a laptop tab is the wrong machine for that job. The middle case is a product that mostly does short clips and occasionally does not, and the honest answer there is to build the editor and set a file-size ceiling you are comfortable defending.

* What you store is source files people chose to keep and the exports they made, so the number depends entirely on whether you keep either. Supabase Free includes 1 GB of file storage and 5 GB of egress a month. Pro, from $25/mo, includes 100 GB of storage and 250 GB of egress, then charges $0.0213 per GB stored and $0.09 per GB served. Deleting an export a week after it was downloaded is the single cheapest decision available here, and it belongs in your retention rule rather than in a bigger plan.

Whichever column you pick, the running cost afterwards is storage and hosting rather than compute, and it stays that way whether ten people or ten thousand are exporting, because every one of them brings their own processor to the job.

Prices and rates from supabase.com, developex.com and claude.com, checked August 2026.

Nothing here is worth memorizing. These four just need to exist on your machine. From step 01 on, you say what you want and Claude Code runs the commands.

1. 01

   Set up the project

   An empty app running against your own database, plus a notes file so Claude Code stops renaming your concepts halfway through.

   PromptSet up the projectCopy

   Set up a new React 18 + Vite + TypeScript project with Tailwind and the Supabase JS client. Read VITE_SUPABASE_URL and the publishable key (the sb_publishable_… key, which replaces the older anon key) from .env, and add .env to .gitignore in the same step so neither value reaches GitHub. Add a typed Supabase client under src/lib, then write a short CLAUDE.md describing the stack and the vocabulary for a browser video editor (projects, videos, clips, exports) and noting that all video processing happens client-side and nothing is uploaded for editing.

   Put the client-side rule in CLAUDE.md now. It is the assumption every later step depends on, and the one an assistant is most likely to quietly break by reaching for a server.

2. 02

   Prove the encoder works before building anything on it

   Load FFmpeg into the page and cut one clip with it. No timeline, no database, no design: just a file in, a trimmed file out. If this step is going to fight you, find out now.

   PromptGet FFmpeg running in the browserCopy

   Add @ffmpeg/ffmpeg and @ffmpeg/util, and build one throwaway page that proves the encoder works: a file picker that takes a local video, two number inputs for a start and end time, and a Trim button that runs ffmpeg in the browser and offers the result as a download. Use the single-threaded @ffmpeg/core, loaded through toBlobURL so the CDN files are not blocked by CORS, and show the real progress events rather than a spinner. Tell me what happens on a large file, and what the practical size limit looks like on this machine.

   Single-threaded on purpose. The multithreaded core is faster but needs cross-origin isolation from your host, which is a hosting decision rather than a build one (see the hosting section below).

3. 03

   Build the timeline, and nothing else

   The screen the product lives or dies on. Ask for it on its own, with fake clips if that helps, and spend the time getting the interaction right before real data arrives.

   PromptBuild the timelineCopy

   Build the editor screen: a horizontal timeline holding clips end to end, each draggable to reorder and trimmable from either edge, with a playhead, a ruler in seconds, and a preview above it that stays in step with the playhead while scrubbing. Keep the timeline state in one place so a clip’s in-point, out-point, and position are always derived from it rather than tracked separately. Use placeholder clips for now. The encoder and the database come after this feels right.

   The bug to watch for is state kept in two places: a preview that disagrees with the timeline after a trim is the symptom, and it gets much more expensive to fix once other features read the same state.

4. 04

   Add accounts, projects, and the rules that keep them apart

   Now the ordinary application work. Sign-in, saved projects, and access rules so one person’s work is theirs alone.

   PromptAdd auth, projects, and access rulesCopy

   Add Supabase Auth with email and password: sign-up, login, logout, a persisted session, a profiles row per account, and a useUser hook. Then the data model as migrations: a projects table owned by a user, a videos table for media belonging to a project, and an exports table recording each finished render with its settings. Add an app_role enum of 'visitor', 'user', and 'admin' with a user_roles table, kept out of the user's own metadata so nobody can promote themselves, and a SECURITY DEFINER has_role function. Then enable row-level security on all three tables so a user reaches only their own rows and an admin reaches everything, with explicit WITH CHECK clauses on insert and update. Show me how to verify a second account gets nothing back for the first account's projects.

   Simpler rules than most templates: everything belongs to exactly one person. Worth getting exactly right precisely because it is simple. A leak here has no excuse.

5. 05

   Wire the real export, with the formats you actually offer

   Connect the timeline to the encoder, add the reframing presets, and make the progress honest. This is where the editor becomes a product.

   PromptBuild the export flowCopy

   Connect the timeline to the encoder. An Export action should build the ffmpeg command from the timeline state (trims, order, and the chosen aspect ratio), run it in the browser, report real progress, and hand back a file. Offer widescreen, vertical, and square as presets rather than a free-form crop. Write a row to the exports table when one completes, with its settings and duration, and generate a thumbnail for each clip locally while you are there. Handle the failure cases out loud: too large a file, an unsupported format, and a tab that runs out of memory mid-export.

6. 06
   Destination

   Add demo mode and the admin view, then use it as a stranger would

   Finish with the two things that sell it and keep it running, then open it in a private window and edit something without an account.

   PromptAdd demo mode, admin, and testCopy

   Add two more pieces. A demo mode: a visitor with no account gets a throwaway workspace with a sample clip, backed by its own demo tables so nothing they do touches real data. And an admin view over storage used, exports run, and accounts, readable only by the admin role. Then run the app and walk me through the whole thing: open the demo as a signed-out visitor and cut the sample clip, sign up, add a real file, trim and reorder it, export it vertically, and check the export appears in the dashboard and in the admin view, and fix whatever breaks on the way.

Review the access rules (row-level security policies) on every table. For each one, tell me in simple terms who can view, add, edit, and delete records, confirm that people can only reach their own data while the right roles can reach more, and flag anything left open that shouldn’t be.

The one rule that matters: the database service key, and any AI provider key you add later, never go into the app or a public repo. If one gets out, treat it as compromised and rotate it the same day.

Pick on two things here rather than one. The usual question is whether the plan allows commercial use. Vercel’s Hobby tier does not. The one specific to this build is whether the host lets you set custom response headers, because the faster multithreaded encoder needs them and the default single-threaded one does not. Building on the default and keeping the option open is the sensible order.

Add a "Generate captions" action on the editor that extracts the audio track from the current cut, sends it to a server-side function that calls a speech-to-text model, and returns timed segments. Render them as an editable caption track on the timeline that the user can fix before burning them into an export, and keep the audio out of long-term storage once the transcript comes back.

Add a "Tighten this" action that analyses the transcript and the audio levels for long pauses, filler, and dead air, then proposes a set of cuts as a preview the user accepts, adjusts, or rejects on the timeline. Never apply them automatically, and always leave the original clip intact so the change can be undone.

Add a panel on the export screen that sends the transcript to your ai function and returns a suggested title, a short description, and a handful of tags, sized for wherever the user says they are publishing. Present them as editable drafts rather than final copy, and let the user regenerate any one of them on its own.

Add a "Suggest a thumbnail" action that pulls several candidate frames from the finished cut (avoiding blur, blank frames, and mid-blink shots) and offers them as a row the user picks from, with the option to scrub for their own frame instead. Generate the candidates on the device using the frames you already have, so no video leaves the browser for this.

Each prompt above picks the model that fits the job. As a rule of thumb, that is Haiku for high volume, Sonnet for everyday writing, and Opus for deeper reasoning. Model names move faster than this page does, so check the current list in the Claude docs (linked in the references below) before you build. Send every one of these prompts through that same ai function, so one key and one set of rules governs all of them.