One codebase, many merchant domains.

Keenu One is a restaurant-commerce platform. The storefront is the customer-facing piece: browse a menu, customise items, check out, track the order. The hard requirement was multi-tenancy — one codebase serving N restaurants, each on their own domain (e.g. sirocpk.com), with their own branding, menu and configuration. No per-merchant forks.

I run an agent-assisted workflow on this codebase, and the interesting engineering is the scaffolding that makes it safe at this scale: typed API clients, registry-driven parity suites, design-token contracts and enforced review gates.

Tenant resolution at the edge

Every request resolves its tenant before anything renders. Middleware maps the incoming host to an org id, signs it into an HMAC cookie, and forwards it on a header the browser can't spoof. Client-supplied identity headers are stripped and rebuilt server-side, so one merchant can never read another's data.

Server-rendered, SEO-first

Pages are server-rendered with structured JSON-LD (Restaurant, Menu, Product, Breadcrumb), dynamic sitemaps and per-merchant metadata — because a storefront that doesn't rank doesn't sell. Cart and client state run on Zustand, versioned and scoped per-org so switching merchants never leaks a basket.

A manifest-driven theme system

The part I'm most proud of. Each theme is a module that declares its design tokens and capabilities in a manifest; the storefront reads that manifest and renders accordingly. It's built as a house of themes — architected to host many — and today three brands run on it in production: Siroc, If You Like Cheese and Down South.

Per-merchant forks were the fast way to ship the first store, but every fork multiplies maintenance and drift. One codebase with a manifest-driven theme system keeps a single surface to secure, test and improve — the cost is a stricter theming contract, which is the right trade for a platform meant to host many.

Tenancy resolves from the host at the edge into an HMAC-signed cookie rather than trusting a subdomain or a client-supplied header — identity a browser can't spoof, so one merchant can never read another's data. Subdomain-only routing would have been simpler but weaker.

Cart state runs on Zustand, scoped per-org, not server state: a basket is cheap and shouldn't round-trip on every tap over a slow connection. Server state earns its keep for catalog and orders — not the cart.

The first merchant — Siroc — running in production on sirocpk.com: branded header, server-rendered menu, category navigation, and the Zustand-backed cart. The same codebase renders any merchant's theme from its manifest.

I'm the primary engineer on the storefront — 72% of the surviving source by git blame (about 137,000 of 190,000 lines across 1,312 files), with the next contributor under 8%. That covers the substance: menu, cart, checkout, order tracking, theming and SEO. Other engineers have contributed along the way. On the storefront's Go BFF I'm the top committer — I built its bootstrap/config, menu and order flows — though the majority of that codebase is the wider platform team's. I also own the storefront's CI/CD and staging deploys. I don't claim the whole Keenu One platform: the merchant dashboard and the backend services are the wider team's work — on the merchant dashboard I built the storefront-config / theming editors. Three merchants are live today; the registry holds eight themes, six of them mine.

Next.js 16 (App Router, React Server Components), React 19, TypeScript, Tailwind CSS 4, Zustand. Server-side integration with a Go BFF (top committer — bootstrap, menu and order flows). SSR + JSON-LD for SEO. Self-hosted fonts and a custom CDN image loader.