Launch video pipeline
Proof
Proof reads a GitHub repository, writes a launch script, guides the recording and renders the result into a product video.
Durable jobs survive redeploys, direct-to-storage uploads bypass request limits and bounded Chromium workers avoid ffmpeg memory crashes.
- Rendered output: A finished 61-second output with timed captions and graphics kept clear of the face.
- Product walkthrough: The walkthrough shows repository analysis, the generated brief and the guided recording flow.
- 1st Runner-Up: Proof placed 1st Runner-Up at 'Sup Build2026 among more than 300 builders.
- Render pipeline: Repository research, recording, Whisper timing, graphics and vision review stay as inspectable stages.
What it does
Proof turns a repository into a guided recording workflow. It drafts a script from the codebase, presents it in a teleprompter and combines the take with product visuals in a deterministic render pipeline.
The result
Proof placed 1st Runner-Up at 'Sup Build2026 among more than 300 builders, with S$5K+ in prizes. The product now runs as an invite-only beta at tryproof.org.
The system boundary I built
Rendering is the part I own end to end. I found and patched an SSRF and an IDOR in my own pipeline. The render worker now requires a token, and row-level security keeps each user's jobs separate.
Jobs are queued, persisted and resumed instead of living inside a browser request. Each attempt is kept so a failed render can be inspected instead of disappearing into a retry.
What broke
Two renders at once were about 20% faster because one could use the container while the other waited on Whisper or an upload. Three exhausted memory and crashed ffmpeg, so I capped it at two and queued the rest. Nothing dropped during the live demo.
Whisper's word timestamps tell the renderer where to cut dead air and place each caption. The measured render time moved from 34.4 seconds to 27.6 seconds without changing the model.
What I learned
A video pipeline is mostly failure handling. Browsers crash, assets arrive late and one bad page can consume the render worker. Durable jobs made those failures visible instead of turning them into another retake.