Can Frame.io be vibe coded?

Build brief — a focused alternative to Frame.io

**Verdict:** Partly, if you narrow it · **Buildability:** 44/100 · **Category:** Audio Video

**Source:** https://www.canitbevibecoded.com/frame-io

Independent editorial assessment from Can It Be Vibe Coded? Not affiliated with, endorsed by, or derived from Frame.io. Verify current pricing and capabilities before acting.

Context

**Frame.io** — Video review and approval with frame-accurate comments, stacked versions, and Camera to Cloud ingest. It currently costs $25/mo.

The review loop itself is not the hard part: a player, timecoded comments, version stacking, and an unlisted share link are a contained effort of work for one editor and a few clients. What you cannot rebuild is the rest of the product · Camera to Cloud from set, the Premiere and Resolve panels that put comments on your timeline as markers, transcoding and CDN delivery that hold up when a client scrubs a 4K cut from a hotel wifi, and the security paperwork studios ask for. Solo and small-shop review is genuinely vibecodeable. Delivery infrastructure is not.

This brief describes a focused, single-operator replacement for the part of Frame.io that is genuinely reproducible. It is deliberately narrower than the product it replaces, and it says so in writing. Build the useful core; do not pretend to have rebuilt the rest.

What you are building

Watch a folder, transcode a proxy with ffmpeg, serve it at an unlisted URL where reviewers leave frame-accurate comments, stack versions, and export the notes as timecode.

Build a focused single-user workflow with real persistence, search, and export.

A responsive interface with real empty, loading, success, and error states.

Requirements

Functional

Ffmpeg.

A VPS with real disk and bandwidth.

A domain plus reverse proxy with TLS.

Chokidar or another folder watcher.

A storage and egress budget you now pay yourself.

Non-functional

Accessibility: semantic markup, labelled controls, visible focus, and reduced-motion support.

Security: server-side secrets, validated input, and no credentials in the client bundle.

Reliability: retries with backoff on external calls, and a clear failure state when a provider is down.

Portability: the operator can export their data and leave without losing it.

Implementation brief

Build me a video review and approval app to replace Frame.io for a one-person edit shop. Requirements:

Node + Express + better-sqlite3 running on my own VPS behind an existing reverse

proxy. Server-rendered pages, one vanilla JS player, no frontend framework.

I drop a master into ./incoming/<project>/<asset>.mov; chokidar picks it up and

ffmpeg writes a 1080p H.264 proxy and a poster frame into

./media/<project>/<asset>/v<N>/. Frame rate comes from ffprobe.

Versions stack: the same asset name dropped again becomes v2, v3, and so on. The

review page gets a version dropdown that swaps the source at the current playhead.

Each asset has one unguessable /r/<random-id> link. A reviewer types their name

once into localStorage, then comments; every comment stores the exact frame and

renders as HH:MM:SS:FF at the asset's real frame rate.

Comments list beside the player and tick along the scrubber. Clicking one seeks to

that frame. Each has a reply thread, a resolved checkbox, and an unresolved filter.

An export button per version writes notes.csv (timecode, author, comment, resolved)

and a DaVinci Resolve marker .txt I can import onto the timeline.

SQLite holds comments and versions, media stays in plain folders, so nothing is

trapped in the app. No accounts and no telemetry: admin pages sit behind basic auth

with the password in .env, share links are the only other way in.

Out of scope: Camera to Cloud, NLE panels, watermarking, and a mobile app. Do not

build accounts, teams, or roles. The unlisted link is the entire permission model.

README: installing ffmpeg, raising the proxy upload limit, and an honest warning

that you now own the storage bill, the egress bill, and the 2am playback outage.

Delivery standard

Inspect the repository first, then write a short implementation plan before writing code.

Deliver the smallest complete end-to-end workflow first; every primary control must work against persisted data.

Use real validation and storage; never substitute fake dashboards, decorative controls, hard-coded success states, or mock integrations.

Include responsive layouts plus genuine empty, loading, success, validation, and failure states.

Keep secrets server-side in environment variables, provide .env.example, and never commit credentials or user data.

Add structured logs around every external call and return actionable errors without leaking sensitive details.

Write unit tests for the core logic and one automated test of the main user journey.

Finish with a README covering setup, architecture, data location, backups, tests, deployment, and known limitations.

Acceptance criteria

A clean install starts the app using only the README and .env.example.

The primary journey works from first visit through saved result, reload, edit, export, and deletion where applicable.

Invalid input, missing configuration, provider failure, and an empty database each have a usable state.

The interface works at 390px and 1440px, is keyboard navigable, and shows visible focus on every control.

Tests, type checking, linting, and a production build all pass with no ignored failures.

No part of the interface implies a live integration, security guarantee, or scale capability that was not actually built and verified.

Non-goals

Do not build these, and do not claim to have replaced them:

Camera to Cloud ingest straight off set.

Premiere, After Effects, and Resolve review panels that sync comments to timeline markers.

A transcode farm and global CDN, so client playback is only as good as your box.

Forensic watermarking, SSO, and the security posture studios require.

Reliability at the vendor's scale is an operations problem, not a prompt.

Connectors, OAuth flows, and vendor API changes require constant upkeep.

What you still own after launch

Run migrations, backups, restores, and dependency updates.

Test the critical journey after every model, API, or hosting change.

Monitor failures and fix the edge cases a first prompt will miss.

Maintain every third-party integration as APIs and OAuth rules change.

Risk

**Operational risk.** The code is achievable; dependable data, integrations, and ongoing operations are the real cost.

Editorial confidence in this assessment: high. No independent one-shot implementation is linked yet.

Prior art

Working open-source software you can read, fork, or borrow from before starting:

[Kitsu](https://github.com/cgwire/kitsu) — Open-source production tracker with a real review loop: versioned previews, annotations, and comments. Heavier than a share link, but the closest self-hosted equivalent

[OpenRV](https://github.com/AcademySoftwareFoundation/OpenRV) — Autodesk's RV, open-sourced under the ASWF. Reference-grade review playback and annotation for desktop; no web sharing layer

Generated by [Can It Be Vibe Coded?](https://www.canitbevibecoded.com) · Full report: https://www.canitbevibecoded.com/frame-io