One of the Frisson projects currently in the works is a website for Racket Tuning, a Dutch racket-tuning specialist. The site is not released yet, so no link for now, but the build is far enough along that the architecture is worth writing about.
The brief is service-first: racket tuning and matching, 3D-printed grip pallets, grip molding, on-court string and play analysis, and stringing. There is a webshop with Stripe checkout, but it is deliberately secondary. Most importantly, the owner should be able to edit everything without touching code.
Payload as the backend
The stack is Next.js 16 with Payload CMS 3 living in the same app, backed by Postgres on Supabase. Route groups keep the two worlds apart: the storefront lives in (app), the Payload admin in (payload) at /admin. Stripe comes in through Payload's ecommerce plugin, alongside the form-builder, SEO, Lexical rich text, S3 storage, and nodemailer plugins.
Pages as blocks, not components
Instead of hardcoding pages, everything is assembled from page-builder blocks (banner, carousel, CTA, content, form, media, archive, three-item grid) with selectable hero variants per page. The frontend is organized feature-first:
src/features/
account/ auth/ cart/ checkout/
page-builder/ product/ shop/
The storefront is localized behind an [locale] segment, and the cart uses parallel routes (@modal, @flyout) so it can slide in over whatever you are viewing, the same trick this blog uses for its about panel.
Two databases, two schema strategies
The part I like most is the deployment model. Development and preview run against a Supabase database with Payload's push: true, so the schema syncs automatically while iterating. Production runs push: false with committed migrations, applied through a manual GitHub Actions workflow gated on a production environment. Fast where speed matters, deliberate where mistakes are expensive.
Still moving
The project started from the official Payload ecommerce template and has been restructured around a collections / globals / blocks / heros pattern since. Two migrations are in flight: Tailwind is being replaced with CSS Modules using CSS @layer and oklch() design tokens, and a PostHog analytics dashboard is planned inside the Payload admin itself, so the owner sees traffic where they already manage content.
Once the service content is in and the site launches, I will follow up with a post about how it held up. Until then: coming soon.