Interfaces that move like products, not slideshows

High-performance interfaces with cinematic animation: GSAP-powered scroll experiences, editorial design systems, and interactions that serve the user instead of just impressing them.

Motion is engineering, not decoration. Done badly it tanks Core Web Vitals, fights assistive technology, and turns phones into hand-warmers. Done properly — transform and opacity only, animations deferred until their section approaches the viewport, reduced-motion preferences honored everywhere — it's what makes a product feel expensive.

This portfolio is the living proof: GSAP ScrollTrigger and SplitText reveals, a scroll-driven timeline, marquee and carousel patterns — built with deferred initialization, accessibility-managed text splitting, and every animation gated behind prefers-reduced-motion. The same discipline applies to client work: the wow factor ships with a performance budget attached.

I work editorial-first: type scales, spacing systems, and design tokens before any animation — so the motion layer has a coherent design system to animate, and your team can extend it without breaking it.

What you get

  • Landing pages and marketing sites with scroll-driven storytelling
  • GSAP builds: ScrollTrigger scenes, SplitText reveals, timelines, magnetic interactions
  • Framer Motion for React state transitions and shared-element flows
  • Design tokens and editorial design systems your team can extend
  • Accessibility-safe motion: reduced-motion variants, focus management, screen-reader-clean markup
  • Performance passes: Core Web Vitals budgets, deferred animation init, 60fps on real devices

How an engagement runs

  1. Design language first

    Tokens, type scale, spacing, and the editorial voice of the page — agreed before a single tween is written.

  2. Static build

    The page ships complete and accessible with zero JavaScript animation — that's the baseline search engines and slow devices get.

  3. Motion layer

    GSAP/Framer animation added as progressive enhancement: deferred until visible, transform/opacity only, reduced-motion respected.

  4. Performance and a11y pass

    Lighthouse and real-device runs, INP and CLS budgets enforced, screen-reader walkthrough — the animation earns its place or it goes.

Proof, not promises

Common questions

Won't heavy animation hurt SEO and performance?
Only if it's built carelessly. The content ships server-rendered and fully crawlable; animation initializes only as sections approach the viewport; and only transform and opacity animate, so the browser composites instead of repainting. This site runs that exact playbook — the animations you see cost almost nothing on load.
GSAP or Framer Motion?
Both, for different jobs: GSAP owns scroll-driven scenes, timelines, and text effects — its ScrollTrigger is unmatched. Framer Motion owns React state transitions, layout animations, and presence. Most rich builds use GSAP for the cinematic layer and Framer for the interface layer.
Can you work from my designer's Figma?
Yes — pixel-accurate implementation from Figma is standard, and I'll flag the spots where a static comp needs a motion decision (what enters first, what the scroll pins, what mobile does instead) rather than inventing them silently.
What about users who get motion sickness?
Every animated experience I ship has a reduced-motion variant: prefers-reduced-motion switches to instant, static presentation with no parallax, no autoplaying movement. It's a WCAG expectation and it's non-negotiable in my builds.