For most of this product's life there was exactly one way in: press record. Everything downstream — the device frames, the cinematic camera moves, the auto-zoom, the captions — worked on footage the app had captured itself.

That was a deliberate choice, and for a long time a defensible one. In v2.1.0 we reversed it. You can now open any video or image straight from the welcome screen and edit it as if it were a recording.

This is the reasoning, including the parts that argued against it.

The original case for staying closed

The argument was not laziness. It came from a real technical advantage.

When the app captures a session, it does not only capture pixels. It captures the click stream: where you clicked, when you typed, which field had focus, how the cursor moved between targets. That metadata is what makes the signature features work.

Auto-zoom is the clearest example. It is not motion detection guessing at what looks interesting — it knows you clicked a button at 00:04 and started typing in a field at 00:11, so it frames those moments. Cursor smoothing works because there is a real cursor path to smooth. Keystroke overlays work because the keystrokes were recorded as events, not inferred from pixels.

An imported file has none of that. It is a rectangle of colour changing over time. So the internal argument for years was: if the best features only work on our own recordings, letting people import files just produces a worse version of the product and a support burden explaining why.

That argument was correct about the features. It was wrong about the users.

What actually changed

Three things, in order of how much they mattered.

The moat moved. When the differentiator was auto-zoom, requiring our own recordings made sense — the feature literally could not work otherwise. But over the last year the centre of gravity shifted toward staging: device frames, 3D stages, environments and lens controls, multi-device scenes, browser windows, and photographs the device sits inside.

None of that needs cursor data. A device frame does not care where you clicked. A camera move across a multi-device scene does not care either. We had spent a year building capabilities that worked perfectly well on any video, while keeping a front door that only accepted one kind.

People kept asking, and their reasons were good. Not "I want to import" in the abstract. Specific situations: a recording from an iPhone that needed a frame. A clip from a colleague who does not use a Mac. A design exported from Figma that needed to move. A Loom that had to go on a landing page. In every case the answer was "record it again in our app", which is a bad answer when the original moment cannot be re-created.

The competitive line had already blurred. We had been describing ourselves in contrast to import-only mockup tools — "from real recordings, not imports" — which was true and was quietly becoming a weakness rather than a differentiator. The interesting position was never "we refuse imports". It was "we can do both, and they can only do one."

What it cost

Opening the door was not free, and pretending otherwise would be the kind of announcement post we try not to write.

A feature matrix that is now conditional. Before, every feature worked on every project. Now some features work only on recordings. Auto-zoom, keystroke display, click sounds and camera PiP all need the click stream, and an imported file does not have one. That is not a bug to be fixed later — it is a consequence of the input. A conditional feature set is harder to explain, harder to document and harder to support than an unconditional one.

A new class of user confusion. Someone imports a video, turns on auto-zoom, nothing happens. From their side that reads as broken. We surface it in the interface rather than letting people discover it by poking at a panel that does nothing, but the honest position is that we traded a clean model for a useful one.

A scope question we had to answer early. Once you accept arbitrary files, "why not add multi-track cutting, ripple edits, colour grading" becomes reasonable-sounding. We wrote the frame down before building anything: this is open a video, then polish it — staging, zoom, captions, export — not become a video editor. Anything that only makes sense in an NLE stayed out. That line will be under pressure forever, and writing it down early is the only reason it has held.

Still images were the awkward part. Video import is conceptually simple. A still is not a video, and making one behave like a timeline clip meant deciding a default duration, hiding panels that make no sense for a static image, and handling odd pixel dimensions that video almost never produces. It was the right call — screenshot-to-mockup is a genuinely large use case — but it was more work than "also accept PNGs" suggests.

The thing that surprised us

We expected imports to be a convenience feature. A nice-to-have for people who occasionally had a stray file.

What it actually did was change who the product is for. Before, you had to be someone who records their screen on a Mac. Now you can be a designer with a Figma export, an iOS developer with a device recording, a founder with a clip someone sent them. The recording features are still there and still the best part for people who use them — but they are no longer the price of entry.

That reframing was uncomfortable, because it means competing in a category we had been positioning against. Mockup tools that never recorded anything were the ones we pointed at to explain what made us different. Now we are partly in their category, holding the thing they cannot do.

We think that is a better place to stand. We are also aware that is exactly what someone would say after making the change, so the honest version is: ask again in six months, when there is data.

What we are watching

Three numbers will tell us whether this was right, and none of them are download counts.

The share of projects that start from an import rather than a recording. If it is small, this was a convenience feature and the effort was misallocated. If it is large, the product's centre has genuinely moved and the way we describe it needs to move too.

Whether imported projects reach export. Starting a project is cheap; finishing one is the signal. If people import and abandon, the conditional feature set is confusing them and the fix is interface work, not more features.

Support volume about missing auto-zoom. This is the cost we accepted. If it turns out to be loud, the messaging in the app is not clear enough about what an imported file can and cannot do.

What we did not do

Two paths were open and we took neither, which is as much a part of the decision as what shipped.

We did not fake the missing data. It is technically possible to infer clicks from a video — watch for the visual change that follows a press, guess a coordinate, place a zoom there. Some tools do this. We tried it, and the failure mode is bad in a specific way: it works often enough to look reliable, then puts a confident zoom on the wrong part of the screen. A feature that is wrong 15% of the time is worse than one that is honestly absent, because the user stops being able to trust the other 85%.

We did not gate imports behind the paid plan. There was an argument for it — imports open the product to a whole category of people who never record, and that is a reasonable place to ask for money. We decided against it because the constraint we were removing was arbitrary in the first place. Charging for the removal of a limitation we imposed reads as a toll booth, not a feature. Opening a file works on the free plan; the paid plan still buys what it bought before, which is 4K, no watermark and no length cap.

Both of those were close calls, and the second one may look naive in a year.

The general lesson

The constraint that made the product good early was real: capturing our own footage gave us data nobody else had, and the features built on that data are still the ones people notice first.

Constraints like that have a shelf life. They are load-bearing right up until the moment most of what you have built no longer depends on them — and then they are just a locked door with a good story attached.

The tell, in hindsight, was that we were spending most of our development time on capabilities that did not need the constraint at all. Every device frame, every camera move, every environment we shipped in the last year worked fine on any pixels. We just were not letting any other pixels in.

If you are carrying an early constraint, the question worth asking is not whether it was correct — it probably was. It is whether the things you are building now still depend on it. When the answer becomes no, the constraint has stopped being a design decision and started being a habit.

Open Media shipped in v2.1.0, alongside Realistic Mockups and Browser Frames. Download Screenify Studio — opening a file works on the free plan.

Why We Opened the App to Files You Didn't Record