What We've Actually Learned Shipping Animation Into Real Products

Most animation on the web is just decoration. It gets tacked on at the end, survives one design review, then just sits there doing nothing.

We don't use it that way. Over the last two years we've shipped Rive into a Layer 1 blockchain landing page, an AI infrastructure site, a Mac menu bar app, and a creator economy mobile app. Four totally different products, four totally different jobs for the animation to actually do.

Here's what we keep seeing, when it works, when it doesn't, and the one project where we got it wrong and had to rebuild the whole thing.

Rive vs After Effects: the real difference

We use both, and it's not about how complex something is. It's about whether it needs to respond.

After Effects is for straight sequences. Something plays, it ends, that's it. A background loop, an illustrated moment, something that plays when you scroll, none of that needs to know anything about the user.

Rive is for anything that has to respond. States, switching between them, interaction, something that acts differently depending on where it is or what the user just did. That's a state machine, and if you try to fake that in After Effects, you end up building it in code afterward anyway, and that's where quality gets lost.

Lemon is the clearest example. It's a voice-to-prompt tool that lives in the Mac menu bar, and a menu bar app is about as tight a design constraint as you can get. It has to feel instant, it has to feel native, and it can never feel like a website pretending to be an app.

Every little interaction in that product is built in Rive, and the reason is flexibility. We weren't animating a sequence, we were building states for interactions. That's the real difference between something that plays and something that responds. Once you need states, the choice is obvious.

Animate the actual product instead of just screenshotting it

RunInfra is an AI model optimization platform, backed by Y Combinator and part of NVIDIA's Inception Program. You drop in a Hugging Face model, it benchmarks GPUs, optimizes the kernels, and deploys a production API.

That's a lot to explain to an engineer who's already decided your landing page is just marketing.

The obvious move is a screenshot of the dashboard. We didn't do that. We designed new UI flows and animated the actual product, using Rive and After Effects together, so the whole thing plays out right on the page. No demo, no signup, no waiting around.

That was our call, not the client's. We pitched it because the alternative is asking a skeptical developer to trust a static image of software they can't even touch. Watching it actually work is a completely different ask than looking at a picture of it.

People assume this kills performance. It didn't. The animated version shipped with no real performance hit compared to the screenshot version we would've built otherwise.

Let the animation explain the thing, don't just decorate with it

Gopher is a Layer 1 blockchain built for AI-powered trading, basically AWS for automated trading strategies. Crypto and AI in one product, which is two of the loudest, most overused categories on the internet stacked together.

Every project in that space uses the same dark theme, same gradients, same buzzwords. Adding more visual noise wasn't going to make us stand out.

So we did the opposite: minimal layout, restrained type, and let the Rive animations do the explaining. Network architecture, trading infrastructure, the stuff that normally gets buried in a paragraph nobody reads, each one got animated instead.

The rule we stuck to: the animation had to explain the thing without dumbing it down. It's easy to make something complex look approachable by making it look simpler than it is. That loses you the exact audience you actually need, because a sharp buyer notices immediately.

Where we screwed up

On one project, the animations we built didn't hold up once they were actually live. We had to remake them.

Not a quick fix. A full rebuild.

The lesson wasn't about Rive itself. It was about building animation files without thinking hard enough about how they'd behave outside the editor, at real sizes, on real hardware, inside a real page. A file can look perfect in preview and still be built in a way that falls apart in production, and you don't find out until it's already live.

We changed how we build files after that. More thought about structure up front, more testing in the real environment before calling anything done. It's the kind of lesson you only learn by getting it wrong once.

Any studio that tells you their animation work has never needed a rebuild has either not shipped much of it, or isn't being honest with you.

Handoff: can the client actually change it later?

This is the question nobody asks during the project and everyone asks six months later.

Rive files are editable, and updates aren't hard. Funny enough, no client has actually come back to change one, but that's not really the point. The point is that they can.

Animation built as something nobody can touch is a liability you're handing someone. If a team has to call the studio just to tweak a motion asset, you didn't deliver a product, you delivered a dependency.

Scale: tens of screens

SideShift is a creator economy platform trusted by 3,000+ brands including Brex and YikYak, connecting Gen Z UGC creators with paid brand opportunities. We redesigned their creator mobile app from the ground up over four months, then designed the full web version of the entire app, heavy on illustration and animation, with Rive bringing it to life.

At tens of screens, animation stops being a design choice and becomes something you have to systemize. Motion has to feel consistent across screens designed weeks apart. Timing, easing, weight, those need to get decided once and locked in, or the app starts feeling disjointed. Every screen ends up slightly off in a way users can feel without being able to say why.

Creators open this app every day to find gigs, apply and get paid, and they'll switch to a competitor the moment it feels clunky or flat. Going heavy on custom illustration, badge systems and animated components only works if you've locked in the motion system before you start cranking out screens.

What we'd tell you before you start

Pick the tool based on whether it needs to respond, not how complex it is. Does it need to respond to the user? Rive. Does it just play? After Effects.

Test it in the real environment early. The editor isn't the browser. We learned that one the hard way.

Decide who owns it after launch, and build it for that person.

Make sure it's actually doing something. On Gopher it explains the architecture. On RunInfra it replaces a demo. On Lemon it makes the interaction feel native. If you can't say what the animation is for, it's just decoration, and decoration is the first thing that gets cut when performance is on the line.