About
Built because the recording was never the hard part
Getting the pixels is straightforward. Getting a video somebody wants to watch, out of a take you made once and cannot make again, is the work.
A raw screen recording is flat. It sits at one distance from the viewer for its whole length, the thing that matters is too small to read, and the pointer wanders about while nothing happens.
Everyone knows what fixes it. Push in on the work. Cut the dead air. Frame the camera somewhere sensible and put the whole thing on a background. And almost nobody does it, because that is an afternoon in a video editor for a five minute clip — so the flat version gets sent instead.
Prequel makes that pass for you. It watches where you click and type while it records, and opens an editor with the zooms already placed, the camera already framed and a background already on. Nothing is baked in: what you change is only what you disagree with.
Then it exports properly — hardware H.264 or HEVC at up to 4K, composited in Metal, at a constant frame rate. A video that looks produced is worth nothing if the file is soft.
Why not just use Electron for all of it
We tried. desktopCapturer and MediaRecorder cannot reach the quality bar: software VP8 and VP9 encoding, dropped frames above 1080p60, no way to exclude a window from its own capture, and system-audio loopback that broke on macOS 15 and stayed broken.
So capture, encode and export are Rust against the platform frameworks, and everything crossing into JavaScript is plain data. No Objective-C object and no CMSampleBuffer ever reaches the Node side — it sees descriptions of things and commands to act on them.
The result is a recorder that holds 1080p60 without dropping frames, an export that runs on the media engine rather than the CPU, and a preview that agrees with the file because both draw the same plan.
Native where it counts
Capture, encode and export are Rust against ScreenCaptureKit, AVFoundation, VideoToolbox and Metal. The shell is Electron because a shell is not the hard part.
Nothing is decided too early
The layout is an editing decision, not a recording one. Anything the app can leave open until you have seen the take, it leaves open.
One implementation, not two
Where the same answer is needed in two places — a position, an audio gain — it is computed once and sent to both. Two implementations is how a preview and an export come to disagree.
Local by default
Recording, editing and export happen on your machine. There is no upload, no queue and no cloud render. Sharing a finished file is the one thing that reaches a server, and only when asked.
Say something
Feature requests, bug reports and disagreements about codecs all go to the same address.