Next.js + Vercel SFCC Composable Storefront

Storefront Next isn't a frontend upgrade. It's how Salesforce gets cheaper to own.

If you're a director of ecommerce on SFCC and you've been treating the Storefront Next conversation as "another frontend refresh with a fuzzy ROI" that's the wrong filing cabinet. Put it back. This one goes under TCO.

The last piece I wrote on this argued that Storefront Next is the upgrade that finally aligns the SFCC frontend with the toolchain the rest of the software industry is using to extract real productivity from AI. That's the engineering manager's case. This is the ecommerce operator's case. They're the same case looked at from different chairs, and the operator's chair is the one with the budget.

Here's the version of the argument that ought to land in front of you, your CFO, and your CIO at the same time.

The "wait and see" math is wrong, and it's been wrong for about a year

Most SFCC clients I talk to in 2026 are doing some version of the same calculation: We know composable is coming. We know our SFRA stack (or worse, SiteGenesis stack) is accumulating tech debt. We’ve thought about Shopify but we’re starting to hear cautionary tales. The next major SFCC release feels close. Let's wait one more cycle. I get the instinct. I fundamentally disagree with it, and here's why.

The waiting calculus assumes a) the cost of upgrade is going up over time and b) the value of waiting is going up too. Both halves of that are now wrong.

The cost of upgrading is going down.

Two years ago, a composable storefront from a top-tier SI ran $1M+ before you started counting integrations. Salesforce's own internal pricing sizing put composable at a $500K minimum floor; they wouldn't even sell it under that number. 

We are now offering production-grade Storefront Next implementations at 64labs in six weeks, in the $150K–$300K range. Yes, six weeks to development done on about 75% of the project. Full flows. Checkout working. To an outsider the project looks finished. (Insiders know where the 25% lives). 

Your UAT is going to take longer than the project itself. How do we do this? By leveraging the headless SFCC experience we gained off the 12 PWA Kit builds that we've shipped to 10 previous customers. We will have built our first Storefront Next site before Salesforce officially launches Storefront Next. The six-week number comes from experience not bluster.

Look, experience still counts. Storefront Next is new but much of the SFCC composable infrastructure (API infrastructure in particular) is the same. The tooling is mature. The patterns are settled. The migration playbook is no longer being written for the first time on your project. That doesn't mean composable is cheap. But it’s way cheaper than having your current team or partner struggle up the learning curve we have scaled in the past four years. The failed composable builds of the past few years are generally down to overconfidence and under-skilling. Not technical gaps in the product.

The value of waiting is going down too.

Every Salesforce roadmap announcement since November 2025: Agentforce Commerce launch, the Cimulate acquisition in February, the ChatGPT/ACP checkout integration, the PWA Kit MCP Server, has assumed a composable foundation. If you're not on it, you're watching the platform you've paid for accelerate without you. That's not "we're behind on a new front-end." That's "we're paying full Salesforce price for a sub-set of what Salesforce can now do."

You wait six more months and you'll wait twelve. Wait twelve and the next release is "right around the corner," so why not wait again. The perfect moment to upgrade does not arrive. At some point you just jump in. The argument I'm making is that the time will never be perfect, so now truly is as good as any other time and better than 12 months from now.

What "lower TCO" actually means here

I know "lower TCO" is the kind of phrase consultants use when they don't have anything specific to say. So let me be specific. Here are the lines on your operating budget that change when you move to Storefront Next.

Implementation cost: goes down.

Already covered above. The number for a fresh Storefront Next build today is meaningfully lower than it was two years ago, dramatically lower than what large SI partners still quote and about what an SFRA upgrade would cost you. And if you use 64labs it’s all over in a single quarter.

Front-end hiring cost: goes down, stays down.

This is the one almost nobody sizes properly. The labor market for SFRA-fluent (and especially SiteGenesis-fluent) front-end developers is shrinking every quarter. The rate you pay for an ISML specialist in 2026 is not the rate you'll pay in 2028, and it isn't going down. Storefront Next runs on React, Vite, Tailwind, and shadcn, a stack you can hire against from any modern front-end pool, anywhere in the world, at market rates. You stop paying a scarcity premium for a skill set that's actively retreating.

Deployment cost: goes down, stays down.

Storefront Next deployments measure in the tens of seconds, not the minutes-to-hours of a full SFRA push. That changes the unit economics of every merchandising-driven release. Teams that deploy eight times a year start deploying weekly. Teams that already deploy weekly start deploying daily without a war room.

3P cost: goes down, stays down.

A lot of SFRA clients I see have at least considered a paid Algolia or Coveo or Constructor.io contract layered on top of Salesforce because Einstein didn't deliver where they needed it. It makes sense to invest in Search. The post-Cimulate Agentforce Commerce roadmap is built specifically to absorb that layer. To get the absorption, you need the foundation. The foundation is Storefront Next. Translation: every quarter you're not on it is a quarter of paying twice for search and discovery.

Engineering velocity: goes up.

‍This is where the prior article's AI-leverage argument lives. I won't relitigate it here other than to note that the productivity multiplier compounds against every line in the engineering payroll, every quarter, forever.

Add those up and you have the answer to "what's the ROI." It isn't a nice-to-have frontend ROI. It's a structural cost-of-ownership ROI that runs across every year of your contract.

SiteGenesis customers: this paragraph is for you specifically

If you're still on SiteGenesis in 2026, the calculation is different in degree, not in kind. Your tech debt is materially heavier. Your hiring market is materially worse. Your gap to current Salesforce features is materially wider. And the cost of carrying SiteGen another two years while you "evaluate options" is the highest version of the same trap above.

The good news: the migration target is the same as everyone else's. You don't need an SFRA layover. Don't let your agency talk you into that one. The right move is to skip SFRA entirely and go straight to Storefront Next. We've done this for SiteGen clients and the timeline is roughly comparable to a SiteGen-to-SFRA project (about 12 weeks), with the dramatically more important difference that you finish on the platform Salesforce is actually investing in.

If you take one thing from this piece, take this: SiteGen-to-SFRA in 2026 is the most expensive indefensible decision you can make this year. You pay full migration cost to land on a platform that's already a generation behind the one you'll need to migrate to next. Stop with the weird math. Stop listening to partners who don’t know how to build composable sites. Migrate once. Move on.

Cimulate and the foundational nature of this upgrade

Salesforce's acquisition of Cimulate in February changes things. The technology, an intent-aware context engine combining real and simulated shopper journey data for product discovery, is being folded directly into Agentforce Commerce. This is not a minor product release. This is Salesforce closing a long-standing gap between native Commerce Cloud capability and the third-party search/discovery layer many forward-thinking retailers have been bolting on.

For SFCC clients on a composable foundation, Cimulate becomes a native capability. For SFCC clients on SFRA or SiteGen, it becomes a thing you read about. That gap is the gamechanger. The unlock for the entire AI commerce stack: Cimulate, Guided Shopping, ChatGPT catalog syndication, the Merchant Agent, agentic checkout, is composable. The front-end isn't where the value lives. But the frontend is the load-bearing wall the value is built on.

That's what "foundational" means in this context. It's not "nice to have for a fresh look." It's "the prerequisite for accessing the next decade of the Salesforce roadmap."

What to do this quarter

If you're on SFCC and not yet committed to a Storefront Next path, my advice is straightforward.

Don't size a multi-million-dollar SI project. The market has moved past that. Get a prototype, same product catalog, same checkout flow, against your real Salesforce instance, about three weeks and about 70% of the site and use that as the foundation for your business case. The cost of finding out is now small enough, somewhere in the $150k to $300k range, that it shouldn't take a board meeting to greenlight.

Don't wait for the next major Salesforce release before evaluating. Every "next" release between now and 2028 is going to assume you're on the new foundation. The decision is not which Storefront Next release to jump in on. The decision is whether your team is still trying to extract value out of SFRA or SiteGen when your competitors are running Cimulate-powered discovery and conversational checkout.

Don't optimize for zero risk. Optimize for catch-up speed. The risk of a six-week proof build is bounded and quantifiable. The risk of a four-year drift on a platform you're paying full freight for is not.

The window for adopting this technology is now thinner than it has been at any point in this generation of SFCC. That's not because the tech is hard to get. It's because the strategic gap between clients who jump and clients who hesitate is now opening at the speed of a Salesforce roadmap built on assumptions you don't yet meet.

You don't need a perfect moment. You need a six-week leap into the future.

There's a moment in most digital commerce transformations where a leadership team looks at their roadmap, looks at their current stack, and realizes the gap between the two is bigger than anyone originally admitted. Storefront Next is, in many ways, Salesforce's answer to that gap.

But calling it just an "answer" undersells it. Storefront Next is a composable, headless storefront framework built on top of Salesforce Commerce Cloud. It replaces the older SFRA (Storefront Reference Architecture) not by tearing everything down, but by giving retailers something far more modern to build on. React-based. API-first. Designed for the kind of performance, flexibility, and speed that today's shoppers expect and today's engineers deserve.

Why the Old Way Stopped Working

SFRA served a purpose. For retailers who needed to get onto SFCC quickly, with a known structure and predictable deployment patterns, it did the job. The problem is that the job changed. Consumer expectations moved faster than monolithic architectures could follow. Page speed became a conversion lever. Personalisation became table stakes. And the development teams responsible for making it all happen were increasingly constrained by a tightly coupled front end that made every change more expensive than it should have been.

The architecture wasn't broken, exactly. It was just built for a different era. Storefront Next is built for this one.

What Makes It Different

The shift to a React-based front end isn't cosmetic. It changes how teams build, how fast pages load, and how easy it becomes to iterate. Components can be developed and tested independently. Performance optimisations that used to require deep platform knowledge can now be applied at the front-end layer without touching core commerce logic. And because the storefront communicates with SFCC through APIs rather than being baked into it, the whole surface area for experimentation gets dramatically larger.

This is the composable model in practice, not just in principle. And it matters because the business case for composable architecture is no longer theoretical. Faster deployments, lower cost of change, better site performance: these show up in revenue, in conversion rates, in the ability to launch in new markets without starting from scratch every time.

Storefront Next also comes with a developer experience that reflects how engineering teams actually work in 2025. CLI tooling, local development environments, clear documentation. The friction that used to be a quiet tax on every sprint gets removed. Teams ship faster. That's not a side benefit; it's the point.

The SFCC Context

It's worth being clear about what Storefront Next is not. It's not a reason to move away from Salesforce Commerce Cloud. If anything, it's a reason to feel better about staying. SFCC remains one of the most capable enterprise eCommerce platforms available, and Storefront Next extends that capability into the front end in a way the old architecture never quite managed. You keep the commerce engine. You modernise the experience layer. That's a sensible trade.

What it does require is a genuine commitment to building differently. Headless architecture rewards teams who are ready for it and punishes teams who aren't. The composable model gives you freedom, but freedom without discipline becomes complexity, and complexity becomes cost. Getting the build right from the start matters more than most leadership teams realise until they're eighteen months in and wondering why everything is still taking so long.

What This Means for Retail Leaders

If you're running digital commerce at a significant retail organisation and you're still on SFRA, the question isn't really whether to migrate. It's when, and how. Storefront Next is where Salesforce is investing. The ecosystem is moving in that direction. Staying on the old architecture isn't stability; it's drift.

The more interesting question is how you approach the migration in a way that extracts real value rather than just checking a box. That means thinking about performance targets before you write a line of code. It means aligning your internal teams around what the new architecture actually enables, not just what it technically is. And it means working with partners who have built in this space before, who know where the traps are, and who can help you move at the pace the opportunity deserves.

The retailers who will look back on this period as a moment of competitive advantage are the ones who treated Storefront Next as a strategic decision, not an IT upgrade. The evidence from builds already in market is that the gap between those two framings is enormous.

There is a version of this where you wait, let others go first, see how it shakes out. That version tends to end with a larger gap to close and a harder conversation to have. The architecture is mature. The tooling is solid. The case for moving is clear.

What's left is the decision.

Composable commerce promised freedom. You could pick the best CMS, the fastest search tool, the slickest checkout experience. All modular. All yours. In theory, best-of-breed means never compromising. In reality, it can mean constant juggling, unclear ownership, and platform fatigue before you even launch.

The problem is that a commerce build is by design a mutt. Sure there is thoroughbred blood in the mix but the mixture and combination of great technologies is the point. How do you create the best mutt from impeccable bloodlines is not a challenge dog-breeders face. But IT teams do.  The Marketing Pitch vs. The Operational Reality

The dream goes like this: every vendor in your stack is a category leader. You pair Contentstack or Amplience with Algolia or Constructor, layer in Uniform for orchestration, bring in Dynamic Yield for personalization, and maybe throw in an edge delivery network for performance.

But more tools mean more vendors. More APIs. More SLAs. More platform overhead.

Hidden Costs You Might Not See Coming

Here’s where we see best-of-breed become a burden:

• Integration drag: Most tools work well alone. Together, they need glue. If each integration was built by a different team at a different time with different priorities, that glue can be more of a Post-It note.
• Internal context switching: If the build was not co-ordinated and decisions made about where everything should live that merchants want to do, you can end up with five dashboards and workflows, not one.
• Contract sprawl: You’re negotiating terms, renewals, and support channels across multiple vendors and potentially partners. The aim of composable is fungibility, but do you really have the energy to replace everything if it’s not perfect. 
• Testing complexity: You’ll need to QA not just the tools but the way they talk to each other. That can be hard with multiple ways of creating Dev and Staging environments. It needs thoughtful automation. 
• Ownership confusion: Who’s on call when the PDP fails to render? Is it the front end, CMS, search, or all three? How do you manage triage when everything is interdependent?

Best in Breed v Good Enough

Not all pain is worth avoiding. If the best way to do things was easy, everyone would do it. But if you are going to make decisions around which technologies to emphasize, which to spend time and money co-ordinating then you need to have a way of judging whether the time and effort is worth it. So start there. 

• Does this improve time to market?
• Is there tangible commercial upside I can measure?
• Will this reduce long-term technical debt?
• Can my team operate it without weekly calls to support?
• Do we really need this level of control here?

Tools should be enabling outcomes. Not just checking boxes.

Putting Boundaries Around Your Stack

One of the best things you can do is define lanes. Distinguish right away where you want best in breed and where you want good enough. Some will be different depending on circumstance. 

• Core platform services: These are non-negotiable. Commerce engine, CMS, search. (Though CMS and search will be more or less important depending on how much content and how many SKUs you are talking about).
• Strategic enhancers: These add real business value but can be swapped later. Personalization, recommendations, PIM, payments.
• Nice-to-haves: That animation layer or orchestration layer or Storybook integration might be cool. But it better earn its keep and not overcomplicate other parts of the stack..

Every tool in your stack should have a reason to exist beyond being "the best."

The Decomposable Stack

Many customers should really think first about creating a stack that is decomposable rather than composable. It’s one of the weaknesses of Shopify that there are chunks of the platform that are too difficult to decompose. Checkout is the most obvious, but most enterprise-scale customizations are at least as complex on Shopify as on SFCC.

Happily the vendors in play are now all competing to offer multiple functionality within your stack and where you don’t believe you need (or are yet ready) to take on the co-ordination costs of neatly siloed partner tech, you can usually squeeze great value out of a part of the stack you value already. Contentstack’s personalization technology is fine. Salesforce’s search can be good enough. Amplience’s DAM and AI capabilities work well. 

Sometimes, good enough beats best if the price of best is co-ordination tax that you can’t afford. A slightly less powerful tool that is pre-integrated cleanly can save you months. The beauty of composable is not necessarily what you do at launch but how you use the freedom the stack creates as you gain experience in the reality of a more flexible stack and how you want to compete.

Building a Composable Stack That Works in Real Life

At 64labs, we help customers prioritize. Not all tools are created equal. Not all need to be replaced. A smart composable strategy means knowing where to customize and where to standardize.

We focus on:

• Launch velocity
• Marketing autonomy
• Long-term maintainability

That means saying no to tools that add overhead without a clear return. It means coaching clients to resist the urge to over-engineer.

Composable commerce works when you design the stack with intent and a clear grip on the big picture of what can and should be achieved right away and what can be decomposed later. 

Best-of-breed is not a shopping spree. It’s a discipline. If you want real agility, focus your stack. Choose fewer tools. Choose the right ones. And build a system your team can actually run without a map.