TFLYXTFLYX®
← Back to the archive

ACT III · Build

Behind the Build: How TFLYX.com Was Designed and Shipped Solo

Next.js, GSAP, WebGL, and a custom motion system — one person, no template, no agency.

ACT III · BUILD🎬 Case Study6 min read

This site is its own portfolio piece. Every scroll effect, every transition, every piece of the timecode HUD at the bottom of the screen was designed and built solo — the same way we build for clients, just with more room to push the craft further.

The brief (that I wrote for myself)

TFLYX runs two tracks — software products, and client websites — and the site needed to sell both without either one feeling like an afterthought. The concept: frame the whole site as a video edit. A scroll-bound timecode HUD. A clickable playhead timeline that acts as a scroll tracker. Film-grain overlay. Cut-style page transitions. Alternating "graded footage" scenes — obsidian black scenes cutting to warm paper-toned scenes, like a colour grade change between shots.

The stack

  • Next.js (App Router) + TypeScript — the foundation, statically-optimized where possible
  • Tailwind v4 — design tokens (Obsidian Black, Momentum Orange, Field-Notes paper) mapped straight into the theme layer
  • GSAP + ScrollTrigger — every scroll-bound reveal, the pinned About-page journey scrub, the colour-grade slider
  • Lenis — smooth scroll that the whole motion system is built around
  • React Three Fiber / WebGL — the projector-dust particle field on the homepage hero, reacting to the cursor

Three things that were harder than they look

1. The playhead timeline

The bottom bar isn't decorative — it's a real, clickable editor timeline where every page section is tagged as a "clip" (data-clip="…") and the playhead position is driven by actual scroll progress. Getting it to feel like a real NLE (non-linear editor) timeline, not a progress bar wearing a costume, took more iteration than anything else on the site.

2. Reduced motion, done properly

A motion-heavy site is worthless if it's inaccessible. `prefers-reduced-motion` is honoured throughout — the preloader, hero, scrub timeline and every reveal fall back to static, fully-visible content instead of just turning animations off and leaving broken initial states behind. That's the difference between "we added an accessibility toggle" and actually designing for it from the start.

3. Keeping it fast despite the WebGL

A particle field, a film-grain shader, and scroll-pinned sections are exactly the kind of thing that tank a Lighthouse score if you're not careful. The approach: keep the ambient WebGL layer persistent and lightweight rather than re-mounting it per section, and let dark "scenes" stay transparent so the ambient atmosphere shows through continuously — one room, not stacked boxes re-rendering on every scroll tick.

Content and components are deliberately separated — every price, every headline, every pricing tier lives in src/content/, never hardcoded into a component. That's not a technical flex, it's what makes it possible to update pricing or copy without touching the motion system at all.

What this means for client projects

Nobody buying a Launch or Business package gets a WebGL particle field — that's not the point of this build. What they do get is the same underlying discipline: content and design separated cleanly, motion that's purposeful rather than decorative, and accessibility treated as a requirement, not an afterthought. The flagship site is where the craft gets tested at full intensity. The client sites are where it gets applied at the right scale for the budget and the business.

Want something built with this level of care?

You don't need a WebGL hero to get the same underlying discipline — clean content, purposeful motion, real accessibility.