Rebuilding the buying experience for a six-figure purchase
Rebuilding precious-metals e-commerce end to end: a faster storefront, a clearer buying experience, and an integration layer so the price and inventory on the page are the ones we can honor.
Context
Most e-commerce advice assumes a cheap, impulse buy: cut the clicks, get out of the way, get to checkout. Precious metals don’t work like that. Orders run into six figures, the product is a commodity so the price is public and the margins are thin, and every order is a real object that has to show up at someone’s door. A slow or confusing page doesn’t survive a purchase that size.
The spot price moves all day, so a quoted price is only good for a few minutes, and inventory has to be right at the moment someone buys, not eventually.
The constraint
This is a big, considered purchase, and the old storefront made it harder than it had to be. It was slow, the product pages didn’t help anyone decide, and checkout demanded too much attention across too many steps. When someone is about to spend six figures, a clunky page is reason enough to leave.
A lot of that traced to the platform. The store ran on Magento 2 with its stock Luma front end, which ties presentation to PHP and leaves little room to shape the experience. Adobe’s headless storefront was still early back then, so betting the whole store on it wasn’t safe.
Underneath, the systems didn’t agree with each other. ERP, CRM, and the storefront each kept their own version of the truth, so people reconciled inventory and pricing by hand instead of the software doing it.
The call
Instead of tuning the Luma funnel or waiting for Adobe’s headless storefront to grow up, I decided to build our own. The new storefront is a custom Progressive Web App built with Next.js, React, and TypeScript, talking to the Magento 2 back end over GraphQL. Pulling the front end off PHP templating meant the buying experience wasn’t boxed in by the platform anymore. We could shape it on purpose, and it got faster and more responsive along the way.
That freedom was the whole point. Once we could change and test freely, the wins came from steady UX and conversion work rather than one big redesign. We sped the site up, rebuilt the product listing and detail pages, sharpened the actions that matter like add-to-cart, and cut checkout down to fewer clicks, showing each piece of information where it’s actually needed instead of piling all of it onto the page at once.
Under the interface, I built an integration layer to sync ERP, CRM, and e-commerce data, so the price and availability a customer sees are the ones we can actually honor. In this category accurate pricing isn’t a nicety. A wrong number on the page is a broken promise on a six-figure order.
The biggest lever on order value turned out to be bundling. Packing simple products into bundles is a merchandising move, but the old stack couldn’t carry it. A single bundle might hold two hundred or more simple products, and Magento’s quote-and-cart logic buckled under that. We reworked how bundles were built and listed so add-to-cart, price calculation, and the price math at checkout stayed fast even on big bundles, and so a change to one simple product flowed correctly into every bundle using it. Bundles that used to be too slow to bother with became the main reason a typical order grew.
The tradeoff
Building our own storefront meant owning it. A PWA front end against a Magento back end is two systems to keep in sync instead of one, and the overhead is real: every upgrade, integration, and fix has to account for both sides of the GraphQL boundary. I took that ongoing cost knowingly, in exchange for control over the experience and the freedom to test that the stock platform would never have given us.
The outcome
Conversion improved. Average order value improved. Both moved at once, which is not how it usually goes.
What I’d do differently
Since the platform is live, this is really what I’d change next. The thing that nags at me is maintenance. Keeping a custom PWA in sync with a Magento back end is more overhead than the payoff should ask for. If I started over, I’d either step away from the PWA architecture or lean on a more AI-driven, streamlined front-end process to cut the cost and complexity of running the two together, so more of the effort goes into the experience and less into keeping the plumbing lined up.