



A motion practice. We decide how fast your product is allowed to be, write it down as numbers engineering can ship, and publish the spec for every project on this site.
Motion arrives in a product one component at a time, each with its own duration picked by whoever built it that week. Nothing is wrong on its own. Together they read as an interface that cannot make up its mind.
We replace the forty decisions with four curves and a table of durations, then prove the result on the hardware your users actually hold.
How we work
Every motion in every project resolves to one of four published easing curves. There is no fifth.
Motion that cannot hold sixty frames on mid-range hardware does not ship, however well it reads on a workstation.
The curve, the duration, the stagger and the trigger. If we cannot say what a motion is, we have not finished designing it.




Four curves, the same distance, the same duration. Fire them and watch where each one spends its time. This is the whole argument for naming them.
No retainers. Motion work has an end: the system ships and engineering owns it.
A read of what your product's motion is doing now, and what it costs.
The whole system: curves, tokens, choreography and the handoff that keeps it alive.

The same duration reads as crisp on a desktop and sluggish on a handset. The cause is not the number — it is what the hand is doing while it waits.

A staggered list is charming at six items and unusable at sixty. The budget is the total, not the increment.

Most reduced-motion branches are written as an apology — everything switched off. The users who need them are the ones who get the worst version of the product.
Only the motion, and that is deliberate. We work on top of an interface you or another studio has already designed. The constraint keeps us honest — motion that only works if the layout changes is not a motion problem.
Named curve tokens in code, a duration and stagger table, per-transition documentation pointing at the token it uses, a reduced-motion branch, and working prototypes in your own stack. Not a video.
Yes, and it is the common case. We add a motion layer to a system that already has colour, type and spacing settled. If the system already has motion tokens we audit them before proposing anything new.
Because a fifth is almost never a motion decision — it is an unresolved argument. Four covers entrance, user-initiated, state change and dense movement. Constraining the set is what makes a product feel like one product.
Rarely. Our work is product motion — the things a user meets a hundred times a week, where a wrong duration compounds. A launch site meets its user once and is a different discipline.
Frame budgets on real hardware before and after, and task timings where the flow has a measurable completion. We publish both, including the cases where the number did not move.
Then the Audit is the wrong shape and we will say so. Single-flow work is quoted directly — there is no minimum engagement and no retainer to sit inside.
No. Motion work has a natural end: the system ships and engineering owns it. A standing monthly fee would give us a reason to keep finding work, which is the opposite of the incentive you want.
The most useful first message is not a brief. It is the one screen that annoys you every day and the reason you have not fixed it.