Building PULSE: An AI-Fitness Website with a Headless CMS

A cinematic AI-fitness product site where every section - hero, programs, pricing, testimonials - is editable from a login-protected admin panel. How I built PULSE with Next.js and a deployable headless CMS.

PULSE is presented as an AI coaching platform - a dark, cinematic fitness product site with an animated hero, integration marquees, programs, trainers, pricing and testimonials. The interesting part is what sits behind it: a working headless CMS with an admin panel, so every section of that site can be edited without a developer and without a redeploy.

Two products in one

Building PULSE meant building two things at once. The public side is the marketing product experience - React Server Components rendering animated, glassmorphism-heavy sections. The internal side is an admin panel where those sections are content, managed through schema-driven forms.

What the CMS controls

• Hero copy, badges and buttons
• Integration marquee items (Apple Health, WHOOP, Oura and more)
• Stats and animated counters
• Feature grid - AI Coach, form check, nutrition, recovery score
• Testimonials and trainer cards
• Pricing tiers plus corporate and student plans
• FAQs, programs, nutrition meals and videos

Each entity type is described declaratively, and one generic engine provides create, read, update, delete and reorder for all of them. Adding a new content type is mostly a schema definition rather than new endpoint code.

The content pipeline

Public pages fetch one typed content bundle from the CMS API at runtime. If the CMS is unreachable - a cold start, an outage, a bad deploy - the site falls back to bundled default content, so the public page never renders broken.

const content = await getContent(); // CMS bundle
return content.sections.hero ?? DEFAULT_HERO; // graceful fallback

Admin auth without cookie pain

The admin panel is login-protected with HMAC-signed bearer tokens instead of cookie sessions. Modern browsers are increasingly aggressive about third-party cookies, which silently breaks a lot of admin dashboards. Bearer tokens avoid that class of bug entirely.

Media, the forgotten half of a CMS

A CMS without media management is a half-product. PULSE's admin includes a media library backed by Cloudinary - images and video uploads with type validation and size limits - so banners and program artwork live next to the content that references them.

Shipping as a serverless monorepo

The frontend and backend live in one repository and each deploys to Vercel independently. The backend is compiled into a single self-contained serverless function so there are no runtime import-resolution surprises, and it auto-creates its schema and seeds data on first request. The database layer exposes one async API over SQLite locally and managed PostgreSQL in production - the same code, switched by an environment variable.

What I would highlight

• End-to-end CMS to pixels: edit a testimonial in the admin and the live homepage updates with no redeploy.
• One database adapter for two backends - SQLite in development, Postgres in production.
• Serverless-hardened Express with lazy schema init and guarded cold starts.
• Auth designed for the modern browser, not against it.
• Default-content fallback that keeps the site online even when the CMS is down.

PULSE was the project where I stopped building websites and started building systems around websites. The public page is the visible product; the CMS is the product that lets the page stay alive.