GSAP Developer for Studios: The Mark Woodland Build

When a studio hands you a finished design direction and says "make it feel alive, and make sure it stays up," they're really asking for two people in one: a motion engineer and someone who owns the server. That's the role I play as a GSAP developer for studios — and the Mark Woodland site is a clean example of it. Uncommon Studio owned the design and art direction; I built the front-end motion, wired the video experience, and set up the server and deployment so it ships and stays fast. This post breaks down that build from the developer's side: what a studio actually gets when they bring in a specialist for the motion and the infrastructure.

Who built it — and the split that matters

The Mark Woodland site was designed and art-directed by Uncommon Studio (Oliver Muñoz) — the same Australian studio I built the Mat Voyce kinetic-typography portfolio with (an Awwwards Site of the Day). My role on Mark Woodland was front-end development, server setup and deployment. Uncommon designed it; I made it move and I made it run.

That split is the whole point of hiring a specialist developer instead of stretching a design team across the build. Mark Woodland isn't an artist or a studio — he's a founder and systems-reform advocate whose ventures span EdTech (Xplor), aged-care AI (Kismet) and housing (Dwell). A site like that has to read as credible and premium: measured motion, flawless video playback, and zero downtime. None of that is design work — it's engineering. When the motion and the infrastructure are handled by someone who does only that, the design direction lands at full strength instead of being diluted by a generalist's compromises.

The brief from a developer's chair

Uncommon's design leaned on three things that all live or die in the front-end:

• A directed intro sequence. The site opens with an animated loading sequence — the first impression of a founder's credibility, so it had to feel authored, not like a spinner.
• Interactive video, everywhere. Mark's presence is media: talks, podcast appearances, video commentary. The site had to present video crisply without the usual autoplay-everything performance tax.
• It has to stay up and stay fast. A thought-leadership site that 404s during a press cycle is worse than no site. Someone had to own the server and the deploy pipeline — not just push a build and hope.

The craft: GSAP motion that reads as authored

The entire motion system runs on GSAP. The discipline that separates a premium studio build from a template is treating motion as one coherent language — a single set of eases and a consistent timing scale — rather than a pile of one-off animations. Section reveals are driven by ScrollTrigger off a shared vocabulary so the rhythm stays consistent from the hero to the footer:

import gsap from 'gsap'
import { ScrollTrigger } from 'gsap/ScrollTrigger'

gsap.registerPlugin(ScrollTrigger)

// One reveal language, reused everywhere — this is what reads as "designed"
gsap.utils.toArray<HTMLElement>('[data-reveal]').forEach((el) => {
  gsap.from(el, {
    yPercent: 16,
    opacity: 0,
    ease: 'expo.out',
    duration: 1,
    scrollTrigger: { trigger: el, start: 'top 84%', once: true },
  })
})

The intro loader is a single GSAP timeline rather than a CSS animation, so the reveal of the page can be sequenced off the same clock — the loader clears and the hero content lifts in as one continuous motion, never a hard cut to a static frame:

const intro = gsap.timeline({ defaults: { ease: 'expo.inOut' } })

intro
  .to('[data-loader-bar]', { scaleX: 1, duration: 1.1, ease: 'power2.inOut' })
  .to('[data-loader]', { yPercent: -100, duration: 0.9 })
  .from('[data-hero] [data-stagger]', { yPercent: 110, stagger: 0.06 }, '<0.2')

The '<0.2' position parameter is what makes it feel intentional: the hero starts lifting before the loader has fully cleared, so the eye never lands on a dead frame. The deeper mechanics behind this — pinning, scrub, staggered reveals — are in my GSAP ScrollTrigger tutorial.

Video that feels premium without tanking the page

Video is the single biggest performance trap on a media-heavy site. Autoplay a wall of clips and the page chokes on decode. The rule I ship every time: one active video at a time, lazy-loaded, with a poster frame standing in until the clip is actually needed.

const players = gsap.utils.toArray<HTMLVideoElement>('[data-video]')

function activate(target: HTMLVideoElement) {
  players.forEach((video) => {
    if (video === target) {
      video.play()
    } else {
      video.pause()          // never decode more than one clip at once
      video.currentTime = 0
    }
  })
}

Every swap animation only ever touches transform and opacity, so the interaction stays buttery even while a new clip decodes in the background. That's the difference between motion that feels expensive and motion that feels broken — and it's the kind of judgment call a dedicated front-end specialist makes without being asked.

The other half of the job: server setup and deployment

This is where "GSAP developer for studios" quietly becomes more than animation. A design studio's core competency is design — they usually don't want to own DNS, TLS, a Node runtime, and a build pipeline. On Mark Woodland I did, so the studio didn't have to.

The stable, documented path for a Next.js site like this is a production Node server running the built app, fronted by a CDN for static assets and caching, with automated deploys on push. The essentials I set up and verified:

• A production build pipeline — next build in CI, so a deploy is a git push, not a manual ritual that breaks at midnight.
• TLS and a proper domain setup — HTTPS, correct redirects (apex ↔ www), and cache headers so the CDN actually caches.
• Incremental Static Regeneration where content updates without a rebuild, so pages serve static-fast but stay current.
• Uptime that survives a press cycle — the whole reason a founder's site exists is the moment a journalist or investor visits, and it has to be instant every time.

None of that is glamorous, and that's the point. A studio partner who hands back a beautiful build they can't deploy has done half the job. Owning motion and infrastructure is what lets a design team stay a design team.

What a studio actually gets

Strip away the specifics and the Mark Woodland engagement is the model I run for studios: you own the design and the client relationship; I own the front-end motion, the performance, and the server. The design direction ships at full fidelity because the person building it does GSAP and WebGL for a living, and it stays up because the same person owns the deploy.

If your studio wins on design but the build keeps outrunning your team — or you'd rather not own servers — that's exactly the gap I fill. See how the white-label partnership works in my guide to white-label creative development for agencies, and how to vet a partner in choosing a technical partner for creative studios.

FAQ

What was Hon Tran's role on the Mark Woodland site?

Front-end development, server setup and deployment. Uncommon Studio (Oliver Muñoz) owned the design and art direction; I built the GSAP motion system, the interactive video experience, and set up the server and deploy pipeline.

What is a "GSAP developer for studios"?

A specialist front-end developer studios bring in to build the motion-heavy part of a project — GSAP animation, WebGL, performance — under the studio's brand, so the design team doesn't have to stretch into engineering they don't do daily.

Do you handle deployment as well as front-end?

Yes. On projects like Mark Woodland I own the full path to production: build pipeline, TLS, CDN and caching, ISR, and uptime — so a studio gets a site that ships and stays fast, not just a codebase.

How do you keep a video-heavy site fast?

Play only one video at a time, lazy-load clips until they near the viewport, use poster frames as placeholders, animate only transform and opacity on swaps, and respect prefers-reduced-motion for accessibility.

Let's build something that ships

If you're a studio or agency that needs a GSAP developer to own the motion and the deployment under your brand — that's exactly what I do.

• See how I work and start a project on the hire page.
• Browse more shipped, awarded work in the projects archive.
• Ready to talk? Let's talk →

---

Written by Hon Tran — creative developer, founder of hontran.dev, and Awwwards jury member. 11+ years building award-winning, performance-first web experiences (GSAP, WebGL, Next.js) for clients worldwide. Twice nominated for Awwwards "Independent of the Year" and the first Vietnamese developer to win an international web award. hontran.dev · Behance.