Creative Foundary

General notes

1. The brief

   A post-production studio lives or dies on its reel, so the site had to put the work first: video that plays, a full-page scroll that moves like an edit, and as little chrome as possible between a visitor and the footage.

   The second requirement was independence. The studio changes its showreel, services, and client list constantly, and none of that should need a developer. So every section a visitor sees is backed by an editor in a custom CMS.

2. A server that reads the database directly

   The public page is a Next.js server component that reads SQLite directly through a single shared connection, with no HTTP round-trip and no client-side fetching. The whole homepage is server-rendered on first load from typed database reads, then hydrated into an interactive client view.

   The CMS is the mirror image: admin pages are client components that call auth-protected API routes, which verify a JWT cookie before reading or writing the same database. Public reads are direct and fast; writes go through the guarded API.

   • Server Component reads SQLite directly
   • No client fetching on the public site
   • Admin → API → DB, JWT-guarded
   • Clean SSR / client / route-handler split

3. The showcase

   The front of house is built for footage. A hero video sets the tone, a dual-shelf carousel splits broadcast work from reels, and a services list expands inline to reveal detail without leaving the flow. Framer Motion carries the transitions, and a full-page scroll with a dedicated mobile nav keeps it coherent on every screen.

   Around the reel sit the things that convert: an about section with bio and skill tags, a scrolling client-logo marquee, and a contact form whose service chips are themselves editable content.

   • Hero video + full-page scroll
   • Dual-shelf gallery: broadcast / reels
   • Inline-expanding services
   • Logo marquee + editable contact form

4. A CMS for every section

   Every section maps to an editor: the hero video and welcome text, service tabs and their bullet points, the gallery shelves, the about content and portrait, the logo marquee, and the contact-form chips. Nothing on the public site is hard-coded.

   Ordering is first-class. Every sortable list reorders by drag, and the API writes the new order for all rows in a single transaction. Uploads are drag-and-drop, destructive actions go through an accessible confirm dialog rather than a browser prompt, and incoming contact messages are managed with a read and unread flag.

   • An editor per public section
   • Drag reorder in one transaction
   • Drag-and-drop file uploads
   • Read / unread contact inbox

5. Data, auth, and deployment

   Persistence is a single SQLite database in WAL mode with foreign keys on, opened once per process and initialised on first connect. Schema changes ship as inline, re-runnable migrations, singleton rows are enforced with a CHECK constraint, and rate-limit buckets live in the database itself so limits survive restarts.

   Admin access is a bcrypt login that issues an HS256 JWT in an httpOnly cookie, checked before any admin route renders. The whole app ships as a multi-stage Alpine Docker image and generates its own JWT secret if one isn't supplied.

   • SQLite WAL + foreign keys, one connection
   • Re-runnable inline migrations
   • Database-backed rate limiting
   • JWT-cookie auth + Dockerised deploy