Hermes Commerce — three stores, one codebase, no developer to change them

The obvious way to get a second store is to copy the first. It is also the failure this kit exists to avoid: every fix lands twice, and within a quarter the copies have drifted apart.

So everything that differs between stores is a field on a typed StoreConfig: theme, logo, locales, currency, tax policy, shipping, navigation, the homepage as an ordered list of sections, feature flags, page templates. The repo's rule is blunt: adding a per-store difference means adding a config field, never an if (store.id === …).

Types cannot express everything, so defineHermes() rejects bad config at build time: two stores claiming one domain, a path prefix that collides with a locale, a tax rate written as 8 instead of 0.08. A store that would break at runtime does not build.

Tax shows the approach in miniature. A US store adds tax at checkout; an EU store shows VAT-inclusive shelf prices, as EU price-display rules require, and extracts the VAT for the receipt. That is one switch, region.taxInclusive, read by one pricing function, with both paths tested.

Theming works the same way. A store's theme sets CSS variables on :root, and the primitives use only semantic tokens, never a colour. So one component library renders a light, uppercase sports brand and a dark electronics brand with no extra JavaScript, and the section registry is exhaustive by type: a new section with no renderer fails the build.

For "run it yourself" to be true, the client-editable parts of a store have to be data that a non-developer edits, previews and publishes. I built the content store myself rather than adopting a headless CMS, for one main reason: the schemas are the component props. Every section has a TypeScript shape in the kit and a Zod schema in the content package, and a compile-time assertion fails the build if the two drift. A client cannot publish something the kit cannot render. With a third-party CMS I would maintain the same model twice, and the drift would be silent.

Each editable area of a store is a document with a mutable draft and a revision counter, so two Console tabs cannot silently overwrite each other. Publishing validates every draft, writes an immutable version of each one that changed, and creates a release: a snapshot naming one version of every document. The store's live pointer then moves to the new release in one transaction. That pointer is what makes a publish atomic: theme, navigation and homepage go live together or not at all.

Rollback creates a new release that copies an old one's entries, so history only grows. Scheduled publishes store only the documents that changed, and lay them over whatever is live when they fire, so a Friday sale banner does not undo a navigation fix published on Wednesday.

Publishing is also where the guardrails sit. A missing translation for any of the store's languages, an image without alt text, a link to a page that does not exist, or a theme whose colours fail WCAG AA contrast blocks the publish. The Console shows the same checks while the client edits, so nobody meets them for the first time at the publish button.

The preview is the real storefront in draft mode, framed by the Console at phone, tablet or desktop width. A small bridge, active only when the frame's parent is the Console's own origin, reports clicks on sections back to the editor, so a client selects what they want to change by clicking it.

Hermes has a real commerce backend: an adapter for Medusa v2, contract-tested against Medusa on Postgres. But hosting Medusa costs money, and the demo had to be free. So the demo runs on the kit's in-memory adapter, which keeps carts, orders and accounts in process memory.

That worked on a laptop and failed on Vercel. "Add to bag" landed on one function instance and the next request landed on another, which had never heard of that cart. Checkout answered cart_not_found.

The fix keeps the adapter and gives it somewhere to put its state. Both memory adapters take an optional persistence store. Around every method that touches state, the adapter loads the store's state document, runs the call, and saves only if something changed. The save is optimistic: it succeeds only if the stored version is still the one it loaded, and a lost race reloads and re-runs, up to four times. Catalogue reads skip all of it, so browsing never touches the database. The demo keeps the state in the Neon Postgres database it already had, and the functions are pinned to the database's region.

The part I would insist on again is the test strategy: the memory adapters' contract suites run twice, with persistence and without, so the persisted version is held to exactly the behaviour of the original.