Jitter hands you a video, which can't be a working UI. Rive hands you a proprietary format plus their runtime in your app forever. Lottie hands you a JSON blob and a player library. A Figma prototype is a demo somebody rebuilds by hand in code. Four tools, four dead ends.

So the rule is that anything authored in verve has to be expressible in exported code. That single test kills whole categories of feature before they're costed — if the canvas can do something the export can't, the canvas is lying.

It also fixed the pricing, the architecture and the marketing in one move. Lottie and Rive export free too; what they take is a dependency. Ours is zero, so “it’s yours outright” is a claim nobody else in the category can make.

Export is free, unlimited, and needs no account. You can arrive, paste a component, animate it, take the code and leave, having given me nothing — and that's the intended path, not a loophole.

The cap is on saved animations: five on free, unlimited on Pro at $12/month. That charges for the thing that actually costs me something to keep, and for the person who has made verve part of how they work.

The hard rule sits under all of it: free or paid, once you have it, it's yours outright. No runtime, no attribution, no phone-home, nothing that stops working if you stop paying.

The rule that came out of it is the whole fix: if it's invisible it shouldn't be clickable, and if it's clickable it shouldn't be invisible. Everything else was an attempt to have it both ways.

So there's a third state. The canvas shows the component; the timeline shows the animation; the two meet when you ask. The first thing anyone sees on opening a document is their actual component, rendering the way it does in their codebase.

Touching the timeline is what asks — playing, seeking, or any edit that changes a track. Deliberately not every edit: dragging an element around the stage changes its position, and posing the document mid-drag would make the card you're holding vanish into its own opacity-0 keyframe.

The standard I set afterwards is that creation should feel inevitable, not documented. If the way in has to be taught, the way in is wrong.

The same session found two more of the same shape, which is what made it a pattern rather than one miss. A new keyframe copies the current value — correct, because it stops the element jumping — but that means a second keyframe produces a flat segment and nothing appears to animate until you change a value. And a track with one keyframe is a constant, which is standard DAW semantics and still reads as “my animation is broken”.

All three are the same failure: the system was right and said nothing. Correct behaviour that reads as breakage is a design bug, not a user error.

Persistence lives entirely in the chrome — one row above the layers list, reading “Sign in to save” when signed out and blocking nothing. The save control has no lasting on-state: it says Save while there's work to store, ticks, and goes quiet.

Unsaved work is kept in the browser as a draft and comes back with a note on the stage. It restores without asking, and Discard is one click away on the note and in the command palette.

Three rules stop the draft becoming its own problem. What the address asks for wins — clicking a template opens that template, so a draft never ambushes a deliberate choice. A draft never overwrites a newer save, so work from another tab or device isn't clobbered. And a draft made while signed in only comes back for that account, because one slot for unsaved work would otherwise hand someone's pasted source to the next person on a shared machine.

If you have to re-enter a mode for every single use, it isn't a mode. It's a one-shot command wearing a mode's clothing, and the interface is lying about what it is.

Pick mode is sticky now, and Escape, the banner, or the rail toggle all leave it. Modes should be cheap to stay in and obvious to leave.

Double-clicking a component on the stage drills in as well — Figma's group-drill idiom — so the feature has an entry people already know rather than only a small icon they have to find.

Playback libraries can't scrub a spring backwards or sample it at an arbitrary t. A timeline scrubber and draggable spring handles need both — the core interaction was the thing the libraries couldn't do.

And a tool that exports three dialects can't be married to one of them. The dialects have to be codegen targets on top of an internal model, or the product's output is shaped by whichever library happens to be driving the preview.

So the engine is plain TypeScript that imports nothing — no React, no Next, no packages — which is also what makes it testable as pure functions: time in, values out.

So exports get replayed. 111 scenes are generated, run in a real browser as Motion, as GSAP and as CSS, and compared against the engine's own trace of the same animation.

It runs the real libraries rather than a model of them, because the failure being guarded against is precisely the gap between what I think Motion does and what Motion does. Motion is sampled live, since it has no scrub API to ask.

It catches the class of bug that has no symptom in the editor: the preview stays perfect and the exported file drifts, which is the worst possible failure for this product because the user only finds it after they've shipped.