Traditional video rendering happens on a server. A request comes in, a job gets queued, a machine processes the frames, and the finished video gets stored and delivered. It works, but it’s expensive, slow, and scales linearly with usage.
Client-side rendering flips the model. The video renders directly on the user’s device — in the browser or inside a WebView. No server infrastructure, no queue, no per-video cost.
How it works
The rendering engine loads as a lightweight web application inside an iframe or WebView. Your app passes in the user’s data — stats, achievements, milestones, whatever makes their experience personal. The engine composes the frames in real-time using the device’s GPU, exports the result as an MP4, and hands it back to the user for sharing.
Why it scales
Because the computation happens on the user’s device, there’s no central bottleneck. Ten users rendering simultaneously costs the same as ten thousand. Your infrastructure costs are fixed regardless of adoption. If a campaign goes viral, you don’t get a surprise bill.
The tradeoffs
Client-side rendering isn’t free of constraints. Older devices render slower. Battery life matters on mobile. The rendering engine needs to be optimized for performance across a wide range of hardware. But these are solved problems — the same GPU acceleration that powers modern web animations powers client-side video rendering.
The integration story
For your engineering team, the integration is minimal. Place an iframe or WebView in your app. Pass in a JSON payload with the user’s data. The rendering, export, and sharing flow are handled entirely on the other side. No SDK to maintain, no dependencies to manage.