Building a slide-deck website with no backend at all

Most presentation sites die in the room you present them in — no wifi, an expired API key, a database somebody cleaned up months ago. So I inverted the requirement: build a deck that works completely offline, and still ships with a real CMS for editing every word in it.

Stack: Next.js 16 (App Router, Turbopack) · React 19 · TypeScript · Tailwind CSS 4 · Framer Motion

What it looks like

The main deck — 26 horizontal slides

The whole site is a deck, not a scrolling page. Arrow keys to navigate, F for fullscreen, progress bar and autoplay control along the bottom. You can put it on a projector without opening Keynote.

Content slides

Every string you see is deliberately a placeholder (This is a heading, Detail 01), because this is a template, not somebody's finished portfolio. You open it, see what goes where, and replace it.

Item cards with a built-in slideshow

Each item carries multiple images that advance on their own — interval and autoplay are configurable from the back office.

Photo gallery

Data views — statistics and record history

The app tracks five states (Status 1–5) that drive the charts, filters and totals. Rename them to whatever your deck actually measures.

A second theme over the same data

Same documents, a completely different design language: high-contrast serif, parchment palette, organised into numbered chapters. There when the green deck feels too casual for the audience.

4. A floating control that hides off the edge

Anyone opening this deck cold has three questions: how do I edit it, how do I sign in, what does the other theme look like. One gear button in the corner answers all three, so none of it has to be said out loud.

Idle, it retreats halfway off the screen edge and fades to 0.28 opacity — a hint rather than a control sitting on the slide. Move the cursor toward it and it slides back in, fully opaque. It can be parked in any corner or hidden entirely (Shift+D brings it back).

Its placement lives in localStorage behind useSyncExternalStore, deliberately not in the content store: where a viewer parks a button is their preference, and moving it should never touch the deck's data.