A premium football jersey ecommerce storefront — full auth, Stripe checkout and a Postgres/Prisma product catalog, built as a sister brand to Gavi Corner.

Overview
Jersey Corner is a premium football jersey storefront built as a sister brand to Gavi Corner, sharing its design language while running a fully independent Next.js codebase with real ecommerce infrastructure: Clerk authentication, Stripe Checkout, and a Prisma/PostgreSQL product catalog with cart and wishlist state.
Problem
A storefront needs to feel real and browsable long before payments, inventory and auth are fully wired up — and it needs to survive a database not being configured yet without falling over.
Approach
Auth runs through Clerk with signature-verified user webhooks (created/updated/deleted) kept in sync with the app's own user records. Payments go through Stripe Checkout with signature-verified webhooks confirming orders server-side rather than trusting the client redirect. The product catalog is Prisma-backed but falls back to seeded in-memory data whenever `DATABASE_URL` isn't set, so the storefront stays fully explorable in any environment, including one with no database provisioned at all.
Engineering
- Clerk authentication with signature-verified webhook sync (create/update/delete) into the app's own user model
- Stripe Checkout with signature-verified webhooks confirming orders server-side
- Prisma 7 / PostgreSQL product catalog with a seeded in-memory fallback when no database is configured
- Cart and wishlist state managed with Zustand
- Framer Motion micro-interactions and Sonner toast notifications throughout the shopping flow
- Internationalized routing via next-intl, sharing brand fonts and color tokens with Gavi Corner
Result / Current State
Core ecommerce flows — catalog, cart, wishlist, checkout, auth — are in place and functional. Lower priority than the platform-scale projects above, and still evolving.
What I Learned
Keeping two Stripe- and Clerk-driven trust boundaries (payments and identity) both verified server-side, while still letting the whole catalog run and demo cleanly with zero external services configured — the seeded fallback had to be a first-class code path, not an afterthought.
Progressing slowly — not a current priority
