Ambarstores

What the product is built for

Make fashion shopping easier across discovery, product selection and returning-customer tools, while supporting the store’s continued development.

Who it serves

Ambarstores shoppers and the team maintaining the brand, catalogue and store operations.

The product experience

The four-year evolution from Ambar to Ambarstores links brand and store design with ongoing management, SEO and two custom Shopify applications. Product selection and saving items for later are part of the same customer journey, rather than disconnected additions to the storefront.

Technology behind the experience

The theme’s size-selection layer distinguishes Shopify’s default variant from a shopper’s deliberate choice. The wishlist connects storefront controls and customer accounts through application endpoints and customer metafields. Identifier normalisation and duplicate handling keep the saved product data consistent between those surfaces.

A store that keeps evolving

The relationship began with Ambar and developed into Ambarstores. Over four years of continuous work, the engagement connected brand development, full store design, management, SEO and two custom Shopify applications. The scope extends from the first impression of the brand to the behaviour of a product page and the customer tools behind the storefront.

The central challenge is continuity. A fashion store changes as collections, imagery and merchandising priorities change. Its visual identity needs room to develop while the shopping journey remains familiar and the underlying Shopify catalogue remains usable. Design, theme engineering and ongoing care therefore belong to the same project story.

From editorial direction to a working storefront

The redesign exploration establishes a restrained editorial direction: a porcelain background, dark typography and an amber accent, paired with expressive display type and the store’s Archivo body font. Large fashion photography gives the collection its presence; clearer product and category structures give shoppers a route through it.

The prototype works with 47 real catalogue products and their collection membership rather than anonymous placeholder cards. Home, collection and product views explore how that material behaves in a complete journey. The prototype also documents the translation into Shopify: reusable Liquid sections, product-card snippets, native collection filtering and variant-aware product controls. This distinction matters: a design exploration demonstrates direction; the Shopify theme has to preserve real commerce behaviour.

The theme work sits within Shopify’s section and template architecture. Existing URL handles are retained in the redesign plan, connecting visual change to the longer-running SEO engagement. The technical aim is to improve the storefront without making its content structure disposable every time its presentation changes.

The difficult detail: choosing a size

One concrete engineering problem appears on the product page. Shopify resolves a product to a variant before a shopper has necessarily chosen a size. Presenting that default as an intentional selection can make the purchase interaction ambiguous.

The custom size-selection layer holds the purchase action at “Choose size” until the shopper makes a choice. Underneath, Shopify’s variant remains selected so the theme can still resolve pricing and availability. Removing the underlying selection had caused unavailable-combination behaviour, hidden prices and an incorrect notification action; the implementation instead separates commerce state from the visual indication of customer intent.

That logic also accounts for a second, sticky purchase block created after the initial page render. Both controls must respect the same choice, and a URL that already names a variant must preserve the selection the shopper made elsewhere. The result is an implementation designed around the platform’s lifecycle, not just the appearance of a size button.

Custom application development

Two custom Shopify apps form part of the engagement. The available wishlist implementation shows the depth of that work: storefront controls, a dedicated wishlist page, customer-account integration and a server-side application built with Remix and React.

Wishlist items are stored in an app-owned customer metafield through Shopify’s GraphQL API. This keeps the saved list associated with the customer record. Product identifiers coming from Liquid are normalised into Shopify’s global ID format, and adding an item already present leaves the list unchanged. These details keep the theme and application working with a consistent representation of the same product.

The storefront reaches the application through a Shopify app proxy, while separate customer-account endpoints support the account experience. The application handles writes rather than asking the storefront to write customer metafields directly. The complexity lies in connecting the shopping interface, customer identity and platform permissions across those surfaces. The second app is included in the overall scope; its individual feature set is not detailed here.

Development as a sequence of connected workstreams

The project materials trace a progression from visual exploration with the real catalogue, to Shopify theme implementation, to custom behaviour and account-connected functionality. Each layer brings a different review question: does the brand feel coherent, can a shopper navigate the catalogue, does a chosen variant behave correctly, and does a saved item belong to the right customer?

This is a four-year continuous development story. The evolution from Ambar to Ambarstores brings brand, website, management, SEO and custom applications into a sustained programme of improvement. The aim throughout is to make the shopper’s experience as easy as possible. Individual releases sit within that relationship rather than representing a single four-year redesign sprint.

What the work establishes

Ambarstores demonstrates a connected commerce scope: brand and storefront design, platform-specific interface engineering, custom application development and continued management. The most useful technical decisions are often small but consequential, such as preserving a variant deep link or making a wishlist consistent across customer surfaces.

The case study describes the scope and implementation rather than attributing an unverified revenue increase, conversion uplift or ranking gain to the redesign. Its substance is the work itself: a store supported at both the presentation and application layers over a sustained relationship.