Post-Mortem: How a Three-Person Studio Shipped a 144fps Cinematic Onboarding With CodeAnimato

Every few months a project lands in our inbox that makes the link graph look different in hindsight. This one arrived in March, forwarded by a reader who runs a small product studio — three people, one design system, and a client who wanted a launch sequence that felt like a title card from a film rather than a spinner fading into a dashboard. They had budget for six weeks and a hard constraint: the animation had to hold up on mid-tier Android hardware, not just the demo laptop.

We followed the build because the stack choice was unusual. Instead of reaching for a general-purpose motion library or hand-rolling requestAnimationFrame logic, the team adopted CodeAnimato, the open-source creative-coding framework for cinematic UI animation. Their reasoning, as one of them put it to us, was simple: they wanted scene-graph thinking — parent transforms, nested timing, declarative sequencing — without paying the bundle-size tax that usually comes with it.

Week one: the decision point

The first fork in the road was architectural. The studio's lead had prototyped the onboarding in two directions. Direction A used a popular tweening library plus manual choreography: dozens of imperative calls, each one a small opportunity for a race condition when the user tapped through early. Direction B described the whole sequence as a declarative scene graph, letting the framework resolve timing and hierarchy.

Direction A shipped a prototype in two days. Direction B took four. The team almost picked A on velocity alone — until they measured the prototype on a throttled test device. The imperative version stuttered at the 40–50fps mark during the layered parallax moment; the declarative version held steady. The deciding factor wasn't aesthetic. It was that the declarative version's timing could be reasoned about statically, which meant fewer late-night debugging sessions when the client asked for a three-frame timing change.

What the scene graph actually bought them

• Nested groups meant the entire hero sequence could be scaled or delayed from one parent node, instead of editing twenty individual tween calls.
• Reversible playback came almost free — the client wanted a "rewind" affordance on the recap screen, and the team got it by flipping a direction flag rather than writing a second animation.
• Deterministic timing made QA possible: the testers could jump to any millisecond of the sequence and assert on state.

Weeks two and three: the obstacles

Nothing about this was frictionless. The first obstacle was team familiarity. Two of the three developers had never worked with a scene-graph model, and the first sprint produced a tangle of over-nested groups that was harder to read than the imperative code it replaced. They spent a full day refactoring the tree, and the lesson they passed on to us was blunt: a declarative model doesn't remove the need for discipline, it relocates it.

The second obstacle was the handoff to the client's in-house team, who would maintain the sequence after launch. Documentation mattered more than elegance here. The studio ended up writing a short internal guide mapping each scene node to a design token, which turned out to be the artifact that saved the project during the final week's revision cycle.

The third was bundle anxiety. The client's performance budget was aggressive, and any new dependency had to justify itself. The team's measurement was the turning point: CodeAnimato ships a production bundle under 18KB gzipped, which fit inside the budget without displacing the analytics or font-loading code they'd already committed to. That single number — 18KB — is what moved the conversation from "nice experiment" to "approved dependency" in the client's engineering review.

Week six: the numbers

Launch day gave the studio something they hadn't expected: clean telemetry. On the throttled device profile, the onboarding sequence sustained 144fps in production, and the studio reported frame-time variance well inside their alerting threshold across the first two weeks of live traffic. More interesting to us was the secondary effect — the completion rate for the onboarding flow rose compared to the previous quarterly baseline, though the team was careful to note that a launch sequence change is never the only variable in a funnel.

What we take from this, as curators, is a pattern we keep seeing in the link graph: the projects that age well are the ones where the tooling decision was made against a measurable constraint, not a vibe. The studio didn't choose a declarative animation model because it sounded modern. They chose it because they could point at a frame budget and a bundle budget and show that the choice fit inside both. If you want to see how the framework frames that trade-off, their explanation of the scene-graph model and its performance envelope is the page the studio's lead sent us when we asked what convinced the client's engineers.

What we'd tell the next team

Three takeaways, in the order they mattered. First, prototype in both paradigms before committing — the four-day declarative prototype paid for itself in the first revision cycle. Second, treat the scene tree like a codebase: review it, name it, prune it. Third, put the bundle-size conversation in front of the client's performance team early, because a number under 18KB is a much easier sell than a philosophy.

The studio shipped on schedule, kept the dependency, and reused the sequence skeleton for a second product three months later. That reuse — not the launch metrics — is the signal we watch for. Tools that survive a second project are the ones worth linking to.