From prototype to production without losing the magic

There's a specific tragedy in this field: the prototype was magic, and the production version is technically identical but somehow dead. The easing got "standardized". The chaos got linted out. The 60-line experiment became a 600-line component and the feeling didn't survive the move.

01

Name the magic before you move it

Before any refactor, I write one sentence: what exactly makes this feel good? "The cards overshoot slightly and settle like they have weight." "The ripple lags the cursor by just enough to feel liquid." That sentence becomes the acceptance test. If the production build doesn't pass it, the refactor isn't done — no matter how clean the code is.

Magic numbers are only a smell when nobody knows why they're magic. Document the why, keep the number.
02

What actually changes in the port

  • Lifecycle: every animation gets setup and cleanup — timelines die with their components.
  • Data: placeholder arrays become typed models; the wow survives real content lengths.
  • Failure: what happens on a 3G connection, a reduced-motion setting, a 2015 tablet?
  • Ownership: someone who isn't you can change the copy without touching the timeline.

This site went through exactly that pipeline — a single 1500-line HTML file, ported into a typed component architecture with the animation code preserved almost line for line. The structure changed completely. The feeling didn't change at all. That's the goal: engineer the container, never the soul.

next postShaders for people who hate math