Tella

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me screen and camera recording that replaces Tella: clips instead of a timeline, so somebody who cannot edit can still make a good demo video.

STACK
- A browser application using getDisplayMedia and getUserMedia, MediaRecorder for capture
- Node 20+ with Fastify for hosting and sharing, SQLite through better-sqlite3
- ffmpeg on the server for the final render; ffmpeg.wasm only if it must stay entirely local
- Caddy in front

THE IDEA
- A timeline is why most people cannot edit video. Clips are the answer: record a take, keep or discard it, record the next, reorder them. No frames, no scrubbing, no razor tool
- A bad take is deleted and re-recorded rather than trimmed. That is faster for anybody who is not an editor, and it is why this format works
- So the unit is the clip, and the editing operations are: keep, discard, re-record, reorder, and trim the ends only

THE DATA MODEL
- projects: id, name, owner_id, layout_kind, background_json, canvas_size, created_at, updated_at
- clips: id, project_id, position, kind, screen_blob_path, camera_blob_path, duration_ms, trim_start_ms, trim_end_ms, layout_override_json, created_at — kind is screen, camera, both, or an imported file
- renders: id, project_id, path, bytes, duration_ms, status, ms, created_at
- shares: id, render_id, token, password_hash, expires_at, revoked_at, views
- views: id, share_id, at, watched_ms, ip_hash, bot
- Screen and camera stored as separate tracks, not composited at record time. That is what lets the layout change afterwards, which is the second reason people choose this format

RECORDING
- Screen with getDisplayMedia, camera and microphone with getUserMedia, recorded as separate streams so they can be laid out independently
- MediaRecorder into chunks written to storage as they arrive, so a crash loses seconds rather than everything
- A countdown before recording, a visible indicator while recording, and a keyboard shortcut to stop
- Pause and resume within a clip
- Audio levels shown live. A recording with no audio is discovered at the worst possible moment, so warn if the level has been silent for several seconds
- A microphone check before the first take, because bad audio ruins a video that bad video does not

LAYOUT AND BACKGROUND
- The screen recording placed on a background with padding and rounded corners, with the camera as a circle or a rectangle in a corner
- Preset layouts: screen only, camera only, camera large with screen small, side by side, and picture-in-picture — switchable per clip, which is how a demo goes from a face to a screen and back without any editing
- Backgrounds: a solid colour, a gradient, or an image, with the composition happening at render time from the stored tracks
- A cursor highlight and a click ripple, drawn from the pointer positions recorded alongside the video. Recording the pointer track separately is what makes this possible and it costs almost nothing

TRIMMING, MINIMALLY
- Trim the start and end of a clip with two handles and a preview. That is all
- Automatic silence trimming at the ends, offered rather than applied
- No cutting from the middle. That is what re-recording the clip is for, and keeping it out is what keeps the interface usable

RENDERING
- Composite on the server with ffmpeg: the layout, the background, the camera overlay, the cursor effects, and the clips concatenated
- A queue with a concurrency cap, because this is CPU-heavy and unbounded parallelism takes the machine down
- Progress reported honestly, and a hard cap on total duration
- Output as MP4 with a widely playable codec, plus a WebM if you want it, and a poster frame
- Keep the source tracks after rendering, so a re-render with a different layout needs no re-recording

SHARING
- A page per video with a token URL, optionally password-protected and expiring, revocable
- A player that works everywhere: a plain video element with the poster, captions if there are any, and no framework
- View counts and how far people watched, which is the only analytic that matters here — where people stop tells you which minute to cut
- Download allowed or not, per share

CAPTIONS
- Transcription with a local speech model if you want it, producing a WebVTT track. Never send the audio to a third party without saying so
- Captions editable before rendering, and burned in optionally
- A video without captions is a video a lot of people will not watch, especially on a phone with the sound off

OPERATIONS
- .env: DATABASE_PATH, STORAGE_PATH, BASE_URL, SESSION_SECRET, MAX_DURATION_MS, RENDER_CONCURRENCY
- Migrations on boot, each once
- Storage is the real cost here: measure bytes per minute early and set a retention policy per project
- Nightly backup of the database; source tracks per their own policy
- Health endpoint reporting render queue depth and free disk

WHAT MATTERS MOST
Separate tracks and the clip model. Store screen and camera apart so the layout is a render-time decision, and resist every temptation to add a timeline. The moment there is a timeline, the tool is for editors and the people it was built for stop using it.

Give me the repository, the recorder, the render worker, migrations, .env.example, and a README with deploy steps behind Caddy and the browser support caveats.