0%
Aymen
Back to Works
WebShipped2026

Exolimits

Agency website — motion-led marketing site driven entirely by a headless CMS so the team ships copy and case studies without a deploy.

My Role
Frontend Developer
Timeline
Feb 2026 — Jun 2026
Status
Shipped
Exolimits
Overview

Marketing site for the Exolimits agency, built so that motion carries the brand while the content stays entirely out of the codebase: every headline, page section, and case study is a Sanity document. The agency's team writes and publishes in the CMS and the live site picks it up — no build, no developer in the loop.

The front end is Next.js 16 with React 19, querying Sanity directly rather than going through an intermediate backend. GSAP carries the visual identity: scroll-driven reveals sequence each section into view as the visitor moves down the page, and continuously running marquees keep it in motion.

The Challenge

The problem to solve

The page has two owners, and that was the real problem: editors control all of the content, while the animation layer has to choreograph whatever they publish. A conventional marketing site hard-codes its copy, so every tweak becomes a developer task followed by a redeploy; here the agency needed to ship new case studies and copy on its own, while the site's identity rests on heavy GSAP work — scroll-driven reveals and marquees that must run correctly over content whose length and shape are not known in advance.

The Solution

How it was built

The front end reads Sanity directly: content is modeled as CMS documents, and React 19 components render each document type as a page section, so there is no bespoke backend to build or keep in sync between the CMS and the page. Editors publish in Sanity and the site reflects it without a deploy.

The motion layer is GSAP. Reveals are bound to scroll position so sections animate in as the visitor reaches them, and marquee strips run continuously. Animation is attached to the section components rather than to the content itself, which keeps the two ownerships separate — editors change the words and case studies, the components decide how they move.

Key Features

What it does

📝

CMS-driven publishing

All copy and case studies live in Sanity. The team edits and publishes from the CMS, and changes go live without a build or developer involvement.

🎬

Scroll-driven reveals

GSAP timelines bound to scroll position bring each section into view as the visitor reaches it — the core of the site's motion-led feel.

🔁

Continuous marquees

Continuously running GSAP marquee strips keep parts of the page in permanent motion between the scroll-triggered sequences.

⚡

Direct Sanity reads

The Next.js front end queries Sanity directly — no intermediate API server to build, deploy, or keep in sync with the content model.

Technologies Used

Built with

Frontend

Next.js

Next.js 16 renders pages on the server from Sanity data, so a site whose entire purpose is to be found and read ships as SEO-ready HTML instead of a client-rendered shell.

React.js

React 19's component model maps each Sanity document type to one section component, keeping the CMS content model and the page structure in lockstep.

GSAP

GSAP provides the scroll-bound timelines the reveals and marquees depend on — sequencing this much motion is beyond what CSS transitions can express.

TypeScript

TypeScript types the Sanity query results, so a change to the CMS content model surfaces as a compile error in the front end instead of a page that breaks silently.