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.

Composable commerce delivers speed, flexibility, and long-term control. But it also requires teams to think and operate differently. That shift is usually welcome. It can also be demanding. We’ve seen great teams stall out not because the tech was flawed, but because their internal structure wasn’t ready to support the pace and complexity that composable requires.

This article isn’t a warning. It’s a playbook for keeping your team energized, focused, and aligned from kickoff to post-launch.

Composable Projects Move Fast When Teams Are Ready

A good composable project launches in five to seven months. That’s aggressive compared to traditional replatforms. But composable projects also require more upfront decision-making across roles. Headless front ends, modular services, and third-party CMS and search tools all demand active, cross-functional input.

When everyone is aligned, it works beautifully. The velocity feels real. The energy builds. But if roles are unclear or teams are out of sync, decisions bottleneck and projects drag.

Why Teams Lose Momentum in High-Change Builds

Here are a few of the most common causes:

• Unclear ownership: Who owns CMS setup? Who defines search behaviors? Who gets final say on navigation? Who is herding the cats on the client team? Who on the partner side is co-ordinating the relationship? With whom?
• Decision fatigue: Composable means choices. Tools, vendors, models, workflows. It’s easy for teams to lose momentum when everything feels undecided or when it seems like critical decisions are being made at an unfamiliar velocity. 
• Marketing and IT misalignment: One wants control. The other wants stability. Without shared understanding, neither gets what they need.
• Partner overload: Bringing in multiple vendors answering to a client for one build can strain bandwidth if internal leaders don’t have time to coordinate across them.

None of these are deal-breakers. But left unchecked, they make even great technology feel hard to adopt.

What It Looks Like When Team Energy Is High

When a composable project is flowing, it shows. Teams are making decisions quickly. Marketing is using the CMS early. Developers are shaping a front end that matches the vision. There’s a clear sprint cadence. Questions have owners. Decisions have deadlines. Demos feel like progress, not just status.

If your internal team looks like that, you’re in great shape.

Clear Structures That Keep Velocity High

A few principles we’ve seen work:

• Designate a single product owner: Someone with authority, not just visibility or a certificate. This person arbitrates across stakeholders and clears blockers fast. This person should be a little bit frightening to their colleagues but relentlessly accountable for the progress of the project and the things that get in the way.
• Map early who owns what: Be honest about it. Don’t say that someone is responsible for someone else if, in the end, the someone else can turn up and change things later on. That’s not ownership. You need people who when they participate in a decision will make it hold. Define who owns the scope of the CMS build and how they are going to manage it. Who trains on search? Who manages the stream of merchant requirements? Don’t wait until sprint five to figure it out.
• Timebox decision windows: And mean it. You can always optimize later. A fast imperfect decision beats a slow perfect one that never ships.
• Build a joint QA process: IT and marketing will both need to validate components. Build the rhythm into your timeline early and make effective QA processes (not just a headcount) a critical requirement you demand from a partner.

How the Right Partner Keeps Your Team in the Flow

Good partners don’t just scope and write code. They stabilize the decision-making structure. They flag when teams (theirs included) are dragging or when accountability is unclear. They train as they go so internal teams aren’t left catching up after launch.

They also build to a cadence. Better velocity comes from repeating a way of doing things and squeezing out inefficiencies over time. 64labs projects always have a predictable rhythm: planning (across five statuses for each story), backlog review and estimation, engineering commitments, daily accountability, rarely blocked multi-functional flow. Sprint0. Then Scopotype. Then Build to Launch. It goes fast. It is easy for clients to fit into. It gets the job done and makes everyone look good.

Partners should give your team energy, not drain it.

Building Internal Confidence Before and After Launch

Composable puts more tools in your hands. That’s a win. But it also means your team needs to be comfortable using them.

Training isn’t a post-launch event. It happens in every sprint. By the time the site goes live, your team should feel like they already run it. Because they do. But to make this work make sure you have prepared the people you want on the project to have sufficient skills to operate with the partner team building the project. Being an intern that makes the coffee for everyone else isn’t going to work. They have to be able to contribute and ask smart questions.

Post-launch support shouldn’t just be bug fixing. It’s coaching, roadmap review, and iteration planning. If your team is energized after go-live, it means the build process worked.

{{banner}}

Composable commerce works best when your team is clear on their roles, confident in their tools, and supported by a partner who knows how to keep the build moving. Technology can accelerate outcomes. But team energy determines how far and how fast you’ll go.

Set the structure right early, and the rest follows.