Skip to main content
The Commerce Engine starter repository is executable documentation for production storefront architecture. It contains two independent storefront brands implemented across multiple frameworks, allowing developers and agents to compare equivalent commerce features without confusing framework differences with platform behaviour.

Commerce Engine starter projects

Browse the production storefront monorepo.

Repository model

The repository contains two complete visual brands:
  • Linea — a jewellery storefront
  • Little Things — a gadgets storefront
Each brand is implemented across: The shared packages are organized by brand so feature logic and design systems can be reused without forcing one framework’s rendering model onto another.

What the starters demonstrate

The repository is not only a visual theme collection. It demonstrates production decisions that are difficult to communicate through isolated snippets:

Rendering boundaries

Public catalog reads are separated from request- or browser-session work, allowing fast prerendering without creating anonymous sessions at build time.

Session ownership

Storefront SDK bootstrap and Hosted Checkout use one shared session with bidirectional token synchronization.

Catalog UX

Category resolution, faceted search, pagination, variant option state, recommendations, and resilient loading behaviour.

SEO

Route metadata, canonical URLs, Product and Breadcrumb JSON-LD, real not-found responses, and safe serialization of catalog content.

Performance

Prerendering, ISR where applicable, parallel data fetching, stable layouts, image optimization, and framework-appropriate hydration.

Deployment

Framework-specific output and adapters for modern serverless and edge platforms rather than a Node-only architecture.

How agents should use the repository

An agent should not copy an entire starter blindly. It should use the closest implementation as evidence for framework-specific concerns while preserving the target project’s design and conventions.
1

Choose the closest framework implementation

Match the target application’s framework and rendering mode. Use the second brand as a cross-check when a pattern appears brand-specific.
2

Trace the feature end to end

For a feature such as product detail, inspect the route loader/server component, shared feature component, query hooks, URL state, metadata, structured data, and Add to Cart integration together.
3

Separate invariants from implementation choices

Commerce Engine invariants—such as public/session boundaries, variant IDs, or Hosted Checkout token sync—must be preserved. Styling libraries, component composition, and route names can follow the target project.
4

Check recent hardening patterns

Prefer the current implementation over older copied snippets. The starters include practical fixes for stale search responses, category scope, safe JSON-LD, asynchronous bootstrap cleanup, transient API failures, and build resilience.
5

Run the target project's own checks

A pattern working in a starter does not prove it works after transplantation. Typecheck, lint, test, build, and exercise the target application.

Framework evidence checklist

When generating a storefront, inspect these areas in the chosen starter:

Foundation

Catalog

Rendering and quality

Deployment

Important patterns reflected in the starters

Do not silently broaden a category query

A category page should resolve the category first. If the slug does not resolve yet, do not omit category_id and accidentally return the whole catalog. Render a loading/not-found state or retry resolution.

Distinguish missing data from a failed request

A successful product request with no product can produce a real 404. A timeout or server failure should normally produce a recoverable fallback rather than permanently serving a not-found page.

Safely serialize JSON-LD

Product names and descriptions are catalog data. Escape characters that could terminate an inline <script> before injecting JSON-LD into the page.

Guard asynchronous bootstrap cleanup

If a root component unmounts while session and checkout initialization are still awaiting network work, do not recreate the checkout instance after cleanup has already run.

Protect search and wishlist state from races

A slower request must not overwrite a newer query. Likewise, concurrent wishlist mutations should commit responses in a defined order rather than whichever response arrives last.

Running a starter

See the repository README and each application’s .env.example and scripts for the exact commands and deployment configuration.
The starters are reference implementations, not a substitute for the skills package or LLM-first contract lookup. Use skills for decisions, LLM docs for exact current operations and types, and starters for integrated production patterns.