Back to selected work

Frank & Beans

Modernizing an established Magento storefront with a GraphCommerce-based headless frontend while retaining Magento as the commerce backend.

Service
Commerce
Technologies
Magento · GraphCommerce · Next.js
Visit Frank & Beans (opens in a new tab)

What needed to change

Frank & Beans was already an established Australian underwear retailer with a live commerce operation. Its customer-facing storefront needed a modern foundation without discarding the Magento backend, operational behavior, and integrations the business already relied on.

The conditions around the work

  • Magento needed to remain the commerce backend and continue owning the established business behavior.
  • The work had to move an active production store forward without treating the system as a greenfield backend rewrite.
  • Existing commerce integrations and customer flows needed to remain intact through the storefront modernization.
  • Search visibility and storefront performance had to be protected while the presentation layer changed.

Storefront context

An established retail operation.

Frank & Beans is an Australian-owned underwear retailer established online in 2009, with ranges for men, women, and kids and shopping paths for Australia, New Zealand, and international customers.

Frank & Beans cotton underwear campaign with two models in a neutral living-room setting
Public storefront campaign imagery, included to establish the customer-facing retail context—not as evidence of an engineering outcome.

The choices that shaped the system

Keep Magento at the center of commerce

The architecture retained Magento as the backend system rather than replacing a working operational foundation. The modernization focused on the layer customers use while preserving the existing source of commerce behavior.

Introduce a headless storefront boundary

GraphQL became the application boundary between Magento and a GraphCommerce-based storefront built with React and Next.js. That separation made the frontend independently evolvable without misrepresenting the work as a backend migration.

Modernize around production reality

The work was approached as an incremental architectural change around a live operation. Decisions were judged against continuity as well as the quality and performance of the new customer experience.

How the work moved into production

The customer-facing application was rebuilt as a GraphCommerce storefront using React and Next.js. Magento continued to own the commerce backend, with GraphQL serving as the explicit integration boundary between the two layers.

Work at that boundary focused on carrying the established store’s commerce behavior and integrations into the new presentation layer. Those production responsibilities stayed with Magento instead of being duplicated in the frontend or rewritten as part of an unrelated platform replacement.

The release treated continuity, search visibility, and storefront performance as production concerns while the presentation layer changed. Post-launch field monitoring and commerce reporting then measured the live storefront, keeping the reported outcomes tied to observed behavior rather than the technology choice alone.

What the evidence supports

All Core Web Vitals reached Google’s good thresholds within one month of launch.
Owner-approved post-launch field monitoring recorded all three Core Web Vitals in the good range during the first month.
Lighthouse score improved by 55%.
Owner-approved before-and-after project reporting recorded the relative Lighthouse improvement following launch.
Abandoned carts decreased by 8%.
Owner-approved commerce reporting recorded the relative reduction after the modernized storefront launched.