How long does it take to design an animation product? Six months of building Mografy

From the first time I opened Remotion to Mografy as it is today took me almost six months.

People often ask me how long it takes to build an animation tool. My answer: writing the code isn’t the longest part.

Working out what it should be is.

This isn’t a tutorial but a development diary. I’ll split these six months into stages and be honest about what I built and then cut, which decisions took longest, and what I’d do differently if I started again.

From a Remotion talk to my first project, SwiftClip

I once gave a talk related to Remotion, and while preparing it I got completely hooked on writing animation in code. A video is a React component and time is a variable. That idea changed how I see animation.

Once I was hooked, the first thing I built wasn’t Mografy but SwiftClip: an open-source library of video templates built on Remotion. It’s written in React and TypeScript and has 32 templates. Copy a .tsx file, change the props, and one command renders an MP4. I also made a Claude Code workflow for it that lets AI plan, generate and register videos.

• SwiftClip, Remotion video templates

But after SwiftClip, I realised what I wanted was different from what Remotion is for:

• I design and teach. I wanted a tool I could use in class that students can pick up straight away, not a framework that needs you to understand a React project first.
• I wanted AI to write the animation, with people watching, judging and editing. Claude makes it; the tool previews, checks and exports it.
• I care about the design quality of the motion itself. Easing, rhythm, storyboards and Chinese typography matter more than whether it can render a video.

So Mografy isn’t another Remotion. It tries to answer a different question: once AI can write code, what should a motion design workflow look like? I later boiled that down to Mografy’s tagline:

Claude creates. Mografy shows.

SwiftClip wasn’t wasted. Its templates later became Mografy Templates, and its Claude Code workflow for making videos with AI became the seed of the Mografy Skill.

A first version that looked like traditional animation software

I built the first Mografy on After Effects instincts. A project was a JSON file with layers and keyframes, and GSAP ran the animation. It seemed sensible, because every designer understands layers and keyframes.

The problem was that this structure suited people, not AI:

• To change an animation, AI had to edit long runs of JSON values. It broke things easily and could never explain why something moved the way it did.
• Layers and keyframes can only describe so much. Particles, procedural shapes and data-driven motion got stuck.
• GSAP is built for web interaction. Rendered frame by frame into a video, its timing was always slightly off.

This version wasn’t wasted either. It made one thing clear:

The data format decides how far AI can go.

That’s why, in the next stage, I was willing to throw the whole thing away.

Starting over, with scenes as pure functions of time

After the rewrite, every Mografy scene is a TypeScript module that exports just three things: meta, params and renderFrame(ctx, time, params). Give it a moment in time and it draws that frame. The same time always draws the same picture.

That one decision made many things simpler at once:

• AI can write it. A function is far more natural than maintaining a huge keyframe JSON, and the reason something moves can live in the code.
• Preview and export are the same thing. Whatever frame you scrub to in the player is exactly that frame in the exported video.
• Canvas can draw anything: text, shapes, particles and data animation, without bending to a layer model.

From then on, mografy.json held only project settings, and the old JSON layer format and GSAP were deleted. Then I made the server the only writer. An edited scene is compiled and test-rendered once in headless Chromium, and the player only updates if it works, with the playhead staying where it was.

The time in this stage didn’t go into code. It went into something harder:

Making up my mind to delete things that already worked.

From MCP to a Skill, so AI actually understands motion design

Early on I connected Mografy to Claude with an MCP package, so AI operated the project through tool calls. Later I removed MCP entirely and replaced it with one shared mografy Skill.

The reason was simple. What AI lacked wasn’t tools to call but knowledge of what good motion is. It already knows how to use tools. It doesn’t know on its own which easing to pick, how long a transition should hold, or how to set vertical Chinese text well.

So most of the Skill is design knowledge, not API:

• The 12 principles of animation
• How to write a storyboard
• Writing scenes, camera moves and transitions
• Vertical and horizontal CJK typography
• Video compression and export settings

Today the same Skill serves both Claude Code and Codex. Claude’s workflow is the more calibrated one, and Codex gets an extra motion design reference of its own.

Where this stage took the most time:

Turning the design judgement in my head into documents AI can read, then running and revising them again and again.

Storyboard first, animation second

By now AI could write things that moved, but moving and looking good are far apart. Ask AI straight out for a 15-second video and it often throws everything on screen at once, with no rhythm and no focus.

My fix was to bring what motion designers already do into the workflow:

Every conversation starts by exchanging a storyboard.

The Skill first writes storyboards/storyboard.md, then Claude makes a visual storyboard for me. Only after I confirm the shots, rhythm and copy does it start writing scenes.

This change did more for the finished work than any technical rewrite. It also convinced me that Mografy’s core isn’t a rendering engine but a workflow.

Exports, templates, music, 3D and community

Once the core was stable, the work turned to making it usable for real:

• Export formats: MP4, WebM, Lottie and SVGA from one mografy export, ready for the web, apps and social video.
• Getting started: install with git clone and pnpm install, then run mografy dev. I deliberately removed the default starter project, so the player opens with 16 built-in component scenes to explore.
• Extras: camera moves and transitions, vertical and horizontal Chinese typography and a motion design teaching scene live in extras/, copied into a project only when needed.
• Templates: Mografy Templates, in 9:16 and 16:9 sets, so nobody has to start from zero.
• More: scores written from a scene’s content, Three.js 3D layers and presentations.

At the same time I started running a Discord, a Buy Me a Coffee page and this blog. Honestly, that part is harder than the code:

Building it isn’t hard. Getting people to know it exists is.

So how long does it take to design an animation product?

My answer is almost six months, and most of that time went not into writing code but into working out three things:

• Who is it for? It took me a while to admit that Mografy isn’t competing with Remotion for developers. It’s for designers, students and anyone who wants to do motion design with AI.
• How do AI and people split the work? AI makes it, the tool shows it, people judge it. Once that was settled, the data format and whether to keep MCP both had answers.
• What has to go? JSON layers, GSAP, MCP and the default starter project were all built before they were cut. Every deletion took longer than writing the thing in the first place.

If you only count going from zero to exporting a video, it doesn’t take six months. The time goes into directions you only know are wrong after you’ve taken them.

The rewrite into pure functions was the turning point. Before it I was building animation software; after it, a workflow for making animation with AI.

Advice for anyone building an animation product

• Build an ugly version first, then decide whether to cut it. The JSON layers in my first version taught me more than any planning document.
• The data format matters more than the interface. Especially now, the format decides how far AI can help you.
• Write down your design judgement. Your instinct for what looks better is the product’s real moat, and exactly what AI lacks most.
• Bring professional practice into the product instead of replacing it. A storyboard isn’t an extra step; it’s what makes the work better.
• Start sharing early. Once it’s built, the hardest part is letting people know it exists. The development story is the best content you have, like this post.

Six months is only the beginning

The open-source edition of Mografy will stay free under the MIT license on GitHub. Next, courses will carry the product forward, and the paid Mografy Pro Triangulum is on its way.

• Mografy on GitHub

If you’re building an animation or design tool too, or you’re just curious about the process, come and talk on Discord. I’d love to know:

Which part of building a product takes you the longest?