I built a product to test whether my own SDK was actually good enough
After we published a screen-recording case study, I kept getting sooo many questions about whether people could use the RVE SDK to build a screen recorder.
The source product could, but not necessarily the SDK. So I built one.
The goal was really to push the SDK through a real-world screen-recording use case and find the bits that were missing. It definitely did that; it took longer than expected and exposed plenty of gaps along the way.
But the end result is a working Mac screen recorder built on RVE.
I’m treating this as a real-world test bed for the SDK, so I’d love feature requests, things that feel rough, or anything you think RVE should handle better for this kind of product.
Feature request from the marketing side, since that's where a lot of screen recordings end up.
For UtilitySEO's ads we use single UI elements rather than screen recordings. The problem with raw recordings at feed size is that the text is unreadable and the viewer can't tell where to look. The features that fix this (auto-zoom that follows clicks, crop to the active panel, 4:5 and 9:16 exports) are what turn a recording into a usable promo asset.
That's also a good stress test for the SDK. Auto-zoom needs cursor and click events as timeline data, not just pixels, plus a smooth animated crop across a long clip. If RVE handles that cleanly, it's a strong answer to "can I build a recorder on this?"
Does the SDK expose click and cursor events as editable timeline data, or only the video frames?
Building the reference product yourself finds real gaps, but it has a blind spot worth naming: you already know the workarounds. You'll unconsciously design around the SDK's sharp edges instead of bleeding on them, because you know where the bodies are buried.
The metric I'd actually trust is time-to-first-working-build by a stranger. Ship the recorder, but also screen-share one outside dev building something small with the SDK cold — no hints. The places they get stuck are the API and docs gaps your own build will never find, because you never needed the docs.
Did the gaps you uncovered in the screen-recorder build match what prospective SDK users were asking for, or did the test expose mostly implementation issues users hadn't actually identified?
dogfooding your own sdk through a real product is the only honest test - docs examples never cover the sharp edges. we do the same with swapfile.live's conversion core, every edge case our users hit makes the underlying approach stronger. was there a moment where the product exposed something the sdk tests completely missed?