The See's Candies Storefront Next Build: From PWA Kit to Production

See's Candies is live on Storefront Next.

That makes it the first production storefront running on Salesforce's new composable framework, and the build behind it tells a more interesting story than the launch itself. 64labs started the migration before Salesforce had even finished the codebase, working alongside the platform team in real time while most partners were still waiting for GA.

The result: three production storefronts (Retail, Fundraising, and Volume Sales), over 1,800 pull requests, and a set of lessons about Storefront Next that don't exist anywhere in the documentation yet.

Three Sites

See's Candies isn't a single storefront. It runs three, each with its own checkout logic, promotional model, and operational workflow. Fundraising has a completely separate business rules engine. Volume Sales uses pricing structures that don't exist in standard B2C Commerce.

That complexity is what makes this build worth paying attention to. A single-storefront Storefront Next launch would prove the framework works. A three-storefront launch with this level of business logic proves it works at enterprise scale.

Dima Shevchuk, product owner on the project, said the multi-site architecture surfaced problems that a simpler build never would have. "Single MRT versus multiple MRT rendered some of the previously working redirects impossible," he explained. "When you have the same relative path for each site with different target URLs."

The Migration Path

Migrating from PWA Kit to Storefront Next isn't a full rewrite. The SFCC backend and API layer stay mostly the same. What changes is the frontend architecture: server-side rendering, React Server Components, a different routing model, different state management. For a team with composable SFCC experience, the learning curve is real but manageable. For a team without it, this is where projects tend to stall.

64labs had 12 PWA Kit builds in production before starting the See's migration. The code doesn't carry over one-to-one, but the architectural instincts do: where SCAPI behaves unpredictably under load, which patterns hold up long-term, and which ones become technical debt.

A significant portion of the 1,800+ pull requests went toward third-party integrations, the part of Storefront Next delivery that conference talks tend to skip over. DynamicYield for personalization, Bazaarvoice for reviews, Amplience for content management, Cybersource for payments, Experian for address validation, and OneTrust for consent. Every one of those had to be rebuilt for the new architecture.

Helen Martin, who oversaw delivery and integration strategy, said DynamicYield was manageable because the team had recently built it on PWA Kit. "We had a good line in the sand as to what we needed to build in SFN, so most of it was migratable," she said. "The challenge was the minor 20% of edge cases that only surface when you're using it in anger with a lot of UAT data coming through." The team built the integration with active consent from the start, so OneTrust was already handled before See's turned it on in production.

The Phased Rollout

See's didn't go live all at once. The team launched Fundraising first, then Volume Sales, then Retail.

Dima explained the reasoning: "FR and VS are low-traffic B2B sites, very simple, low risk. Retail is much more complex and more things can break. So we proved stability on FR and VS first."

Each storefront got its own go/no-go, its own regression pass, and its own production hardening cycle. The phased approach let the team validate the deployment pipeline, redirect strategy, and analytics parity on lower-risk sites before putting the highest-traffic storefront through a live cutover.

Where the Speed Came From

The most surprising insight from the build might be where the time savings actually came from.

When asked where the speed came from, Dima didn't point to the framework. His take was that Storefront Next itself mattered less than the AI harness and delivery workflows 64labs had built over the six months before the See's project kicked off. The tooling they walked in with on day one did more for velocity than the platform switch.

In other words, the framework is better, but the acceleration came from the operating model 64labs built around it: AI harnesses, task structures designed for LLMs, and delivery workflows that took roughly a year to develop. The framework provides the foundation. The workflow around it is what compresses the timeline.

What This Means Ahead of Dreamforce

Dreamforce 2026 kicks off September 15 in San Francisco, and Storefront Next will be one of the biggest talking points on the commerce side. Most SIs will be presenting their plans for the platform. 64labs will have already shipped it.

The See's build offers something that slides and roadmaps can't: proof that Storefront Next holds up when real enterprise complexity, real third-party integrations, and real revenue are on the line. Whether other partners can get there without the same head start is an open question, but the platform has cleared its first production test.

See's Candies is live. The framework works. And the most useful lessons from the build are the ones Salesforce couldn't have documented, because they only come from being first.

‍