# Build brief — a focused alternative to Rendemo

> **Verdict:** Partly, if you narrow it · **Buildability:** 63/100 · **Category:** Audio Video
> **Source:** https://www.canitbevibecoded.com/rendemo
> Independent editorial assessment from Can It Be Vibe Coded? Not affiliated with, endorsed by, or derived from Rendemo. Verify current pricing and capabilities before acting.

## Context

**Rendemo** — A tool for turning screen captures into polished, shareable product demos. It currently costs $39/mo.

The mechanics of a demo builder are not mysterious: capture or import clips, trim them, add zooms, captions and a background, then render an MP4. An agent can wire that up locally with ffmpeg and a canvas timeline in a focused implementation, and for a solo founder shipping one launch video that is probably enough. What it will not hand you is the taste baked into the presets: the easing on the auto-zoom, the mouse smoothing, the default padding that makes a raw screen recording look intentional. You also lose hosted playback, analytics on who watched, and the ability to re-render at 4K without your laptop fans screaming. Fine if you make demos occasionally, annoying if demos are your job.

This brief describes a focused, single-operator replacement for the part of Rendemo 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

Import screen recordings, arrange them on a timeline with auto-zoom, captions and a padded background, then render an MP4 locally with ffmpeg.

- Transcribe supplied recordings, cut them on a timeline, and export finished files.
- A responsive interface with real empty, loading, success, and error states.

## Requirements

### Functional

- Node 20+.
- Ffmpeg installed locally.
- A browser that supports getDisplayMedia if you want in-app capture.
- Patience for render times on long clips.

### 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 a local-only product demo video editor. No accounts, no cloud, no telemetry.

Stack, no substitutions:
- Vite + React + TypeScript
- Tailwind for UI
- Zustand for editor state
- fluent-ffmpeg driving a locally installed ffmpeg binary, via a small Express server on port 8787
- Projects stored as JSON files in ./projects, media in ./media

Features in scope:
1. Import: drag and drop .mp4 / .mov / .webm files, plus an in-app recorder using navigator.mediaDevices.getDisplayMedia that saves a .webm to ./media.
2. Timeline: single video track, drag to reorder clips, trim handles for in/out points, delete clip.
3. Keyframed zoom: user clicks a point on the preview at a given time and sets a zoom level; interpolate between zoom keyframes with an ease-in-out cubic curve. Default zoom is 1.6x over 700ms.
4. Framing: solid or linear-gradient background, configurable padding, corner radius and drop shadow on the video frame. Presets: 16:9, 1:1, 9:16.
5. Captions: text overlays with start/end time, position, font size, one clean sans font.
6. Preview: canvas-based scrubbing preview at reduced resolution, driven by requestAnimationFrame.
7. Export: POST the project JSON to the server, which builds an ffmpeg filter_complex chain and writes ./exports/NAME.mp4 at 1080p, 30fps, h264, yuv420p. Stream progress back over SSE and show a progress bar.

Out of scope, do not build:
- multi-track audio, music library, transitions beyond hard cuts
- hosted sharing, embeds, view analytics, collaboration
- auto zoom detection from cursor movement
- any login or hosted storage

Requirements:
- Fail loudly at startup if ffmpeg is not on PATH, with the install command in the error.
- No secrets needed, but include .env.example with PORT and MEDIA_DIR anyway.
- README with setup, a worked example project, and a short note on expected render times.
- Type-check clean, no any.

## 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:

- Preset motion design that actually looks good without fiddling: easing, mouse smoothing, sensible padding.
- Hosted playback with a share link, embeds and view analytics.
- Fast cloud rendering instead of pinning your own CPU for ten minutes.
- Template library and brand kits, so every demo looks like part of a set.
- Someone else keeping up with codec and browser capture quirks.

## 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.

## Risk

**Manageable.** A personal version is realistic if you test the critical journey and keep reliable backups.

Editorial confidence in this assessment: low. No reviewed project implementation is linked yet.

---

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