Isaak Lagerman

Case study

01 / 10RUMMA · INDEPENDENT COMMERCE PRODUCTCurrent

A bilingual, headless storefront designed as an independent commerce product—with Shopify serving as the current backend, not defining the customer experience.

A premium DIY and home-improvement storefront with an owned design system, graph-based discovery, configurable product families, localization, optimistic cart interactions and a replaceable commerce boundary.

Red dragon illustration used as temporary artwork for the RUMMA commerce case study

A storefront owned by the retailer.

RUMMA is a premium headless commerce experience for the DIY and home-improvement market. The central idea was to treat the storefront as a product in its own right—not as a themed view of a backend.

The interface is an independent Next.js application with its own design system, navigation, search, localization, product configuration, cart experience and SEO architecture. Shopify currently supplies catalog, inventory, cart and hosted checkout capabilities through a controlled server-side boundary.

That separation gives the retailer two kinds of control: the visible experience can evolve outside a theme ecosystem, and the underlying provider can change without rebuilding the presentation, discovery and localization layers.

Challenge

Theme-led commerce makes the platform responsible for too much of the customer experience. Brand expression, catalog structure, internationalization and complex products become constrained by provider-specific templates and data models.

My contribution

Starting from Vercel's Next.js Commerce foundation, I designed and engineered a substantially different product: the complete customer experience, its typed commerce boundary and the operational tooling required to maintain the catalog.

Approach

Separated the experience layer from products, collections, inventory, cart and checkout through normalized application models and typed server-side capabilities.

Designed an editorial hardware-store identity and multiple server-rendered discovery paths for customers who begin with a task, room, material, brand or technical requirement.

Modeled configurable families, modifiers and accessories around real purchasing behavior instead of forcing every relationship into Shopify's standard variant model.

Built localization, URL-owned refinement, optimistic cart updates, structured SEO, careful caching and administrative automation as parts of one product system.

Experience and infrastructure can evolve independently.

Shopify-specific GraphQL responses never travel through the component tree. External commerce data is fetched server-side, normalized into application models and exposed through capabilities the interface understands.

  1. Customer experience

    Design system, navigation, search, localization, product configuration, SEO, motion and responsive behavior

  2. Commerce domain

    Products, collections, pricing, inventory, cart lines, product families and checkout capabilities

  3. Current provider

    Shopify Storefront API and Shopify-hosted checkout behind a typed server-side implementation

Shopify is used as infrastructure, not as the owner of the customer relationship.

An editorial hardware store

Most DIY retailers prioritize density: grids of similar cards, badges, filters and promotional banners. RUMMA uses magazine-like pacing to give functional commerce more context and character.

Forum serif carries expressive headlines while Montserrat handles prices, navigation, product information and controls. Forest green, paper white, warm cream and subtly tinted neutrals create a recognizable world without decorative color noise.

Motion is part of the same system. Product imagery expands within its frame, headlines reveal with controlled timing, and controls respond physically. GSAP and Lenis coordinate the experience while reduced-motion, data-saving and slow-connection conditions keep the content accessible first.

Discovery modeled as a graph

DIY customers may begin with a room, task, material, brand or technical requirement rather than a product name. The storefront supports editorial selections, departments, subcategories, search, brands, related products, accessories and contextual category links.

The visible hierarchy remains understandable—home, department, subcategory, product—but the underlying information architecture is a graph. One category can belong to several departments while retaining a permanent URL and one deterministic breadcrumb path.

Search, multi-select filters and sorting belong to URL parameters and are processed on the server. State stays shareable, refresh-safe and compatible with browser history, while filtered variations are canonicalized to protect the primary category page.

  • Real server-rendered links before hydration
  • Stable URLs across changing merchandising relationships
  • Desktop refinement and a dedicated mobile filter drawer
  • Complete crawl paths and explicit catalog relationships

Configuration beyond standard variants

Some products require more valid combinations than Shopify's standard option model can express cleanly. RUMMA represents each purchasable configuration as a real product with its own URL, SKU, price and inventory state, then joins siblings through Shopify metaobjects.

Selecting an option navigates to the corresponding sibling product. The exact choice remains linkable, server-rendered, refresh-safe and predictable in browser history, while listings expose only one representative configuration to avoid a catalog of near-duplicates.

The model also distinguishes modifiers from accessories. A modifier belongs to a specific configured unit and remains grouped with its parent in the cart; an accessory is an independent product with its own SKU and inventory. Cart operations use Shopify line IDs so identical modifiers attached to different parents remain independent.

Language and cart state treated as product architecture

Swedish is the default language and English is secondary. Interface language lives in synchronized application dictionaries, while product and merchandising content remains editable in the commerce backend. Locale is explicit in every cached commerce function, so responses cannot leak between languages.

The cart responds optimistically to additions, removals and quantity changes, then reconciles directly with Shopify's authoritative mutation response. Public catalog data and private cart state follow deliberately different caching strategies.

  • Grouped configured products and modifiers
  • Group-level quantity and removal controls
  • Accessible live purchase announcements
  • Touch-friendly interactions and coordinated drawer behavior
  • A safe handoff to hosted checkout

Performance and SEO built into the model

React Server Components are the default. Client JavaScript is introduced only for interaction, browser state or animation, and narrow Suspense boundaries keep product names, prices, imagery, breadcrumbs and key links in the initial server-rendered document.

Tagged caching separates products, collections, pages and menus, with Shopify webhooks invalidating the relevant content. Self-hosted fonts and responsive image optimization reduce external dependencies and payload waste.

Every indexable entity has one canonical URL. Product, collection, brand and breadcrumb structured data is generated safely, Swedish and English pages publish paired alternates, and filtered routes remain navigable without becoming competing search results.

One framework tradeoff was documented explicitly: streamed unknown catalog routes may return a soft 404 before the entity check resolves. I protected them with noindex and verification tooling rather than adopt a build-time allowlist that could block newly published products until the next deployment.

Designed for the people operating the store

A sophisticated storefront fails if routine catalog work depends on fragile manual administration. I built Shopify Admin API tooling for product creation, data backfilling, image cleanup, catalog audits, category-graph synchronization, configurable families, navigation imagery and translation verification.

Mutating workflows support a dry-run-first process. Credentials and privileged operations remain server-side, webhook validation is timing-safe, external content is escaped before structured-data serialization, and Content Security Policy behavior can be evaluated without silently breaking checkout.

Outcome

RUMMA evolved from a commerce starter into a brand-owned retail product whose presentation, discovery and interaction systems can outlive its current commerce provider.

One product system, across design and engineering.

RUMMA is not simply a customized Shopify implementation. It demonstrates how visual direction, frontend architecture and commerce modeling can create a differentiated sales channel without discarding the operational value of an established platform.

The provider boundary does not make a future migration free: another checkout stack would still need order, tax, inventory and payment orchestration. It does mean that work can happen behind the boundary without rebuilding the brand, catalog experience, localization, search or SEO layer.

  • A premium editorial identity outside the Shopify theme ecosystem
  • A retailer-owned experience layer with a typed provider boundary
  • Multiple discovery paths through a complex catalog
  • Product configuration beyond standard variant limits
  • A complete Swedish and English experience
  • Optimistic cart interactions grounded in authoritative commerce data
  • Server-rendered navigation, structured SEO and accessible motion
  • Operational tooling for maintaining the catalog at scale

Deliverables

  • Bilingual editorial storefront
  • Typed commerce integration boundary
  • Graph-based catalog navigation
  • Configurable-product family system
  • Optimistic, grouped cart experience
  • Search, SEO and localization architecture
  • Catalog administration and audit tooling

Technology

Next.js 16, React 19, TypeScript, Shopify Storefront and Admin GraphQL APIs, next-intl, Tailwind CSS 4, GSAP, Lenis, Headless UI, Vercel and Vitest.

Forecasting without friction.

A regulator-ready electricity-demand model adopted by roughly 25% of Swedish grid operators in its first year.

Rejlers electricity-demand forecast model engagement

Have a similar problem?

Bring the context, constraints and desired outcome. I can help define the most useful first step.

Start a conversation