What the Cassette launch taught us about shipping motion, not decks

The Cassette work is some of the motion we’re proudest of — a music app where the whole interface breathes in time, transitions that feel like a needle finding a groove. The reel got applause. Then it hit the engineering team’s actual codebase and about a third of it quietly died. This is a post about that third.

Our mistake was designing the motion in a vacuum and presenting it as a finished film. Beautiful easing curves, gorgeous choreography, all rendered at a silky sixty frames per second on a machine with no other job in the world. What we hadn’t done was sit with an engineer and ask the deeply unglamorous question: what happens to this transition on a three-year-old phone with a list of four hundred tracks trying to scroll underneath it. The answer, it turned out, was jank. Our lovely curve became a stutter.

What saved the launch was moving the motion designer into the build. Not a handoff document — an actual pairing, screen next to screen, tuning durations against real device performance instead of ideal-world renders. Half the magic survived intact. The other half we rebuilt to be cheaper, and honestly better, because a constraint forced us to ask which movements were carrying meaning and which were just showing off. The needle-drop stayed. A lot of the decorative flourishes went, and weren’t missed.

The lesson we’ve carried into every project since: motion isn’t a deliverable you toss over a wall, it’s a conversation with the medium it runs on. Now we prototype in code embarrassingly early, on the worst hardware we can find, and we treat a transition that only works on our machines as a transition that doesn’t work. The reel is a promise. Production is where you find out if you can keep it.