5 min read
•
Salesforce
•
August 25, 2025
SFRA was Salesforce’s commitment to building e-commerce sites that could survive and thrive in 2018 and to its credit it was the best choice for an upgrade through 2022 if you could afford it. But its time has come and gone.
If you’re still hearing SFRA tossed around in boardrooms, vendor pitches, and engineering meetings (and you’re not entirely sure what it means) you’re not alone. There’s a lot of chatter, some misplaced nostalgia for last decade’s technology, and very little that’s jargon-free or actually useful. This is a super brief attempt to clear some of that up.
SFRA stands for "Storefront Reference Architecture." (Personally I thought it was Salesforce Reference Architecture, but I guess it can be both). It’s Salesforce’s modern template for building e-commerce sites. In practice, it’s the foundation their Commerce Cloud expects you to use if you want speed, maintainability, and (frankly) access to the latest features fed to you from the Commerce Cloud product team. Where previous generations gave you a “starter kit” built for desktop shopping and slow update cycles, SFRA is in theory designed from the ground up to tackle modern site problems in a modern way. But modernity is the problem. What was modern in 2018 quickly becomes outdated by 2025. For context on the pace of change - Tiktok was only launched into the US in 2017. In web terms 2018 is forever ago.
You have to have a sense of the history of Demandware to really answer this question. Demandware’s winning idea was that you could put ecommerce into the cloud and customers would still use it. But the founding technology of Demandware was Intershop which itself was formed in 1992. That is literally the pre-history of ecommerce and a tribute to Stefan Schaumbach that the whole thing basically still worked..
So what had changed in 2018? Customers had been shopping on their phones for the past five years or so. Brands had become more demanding of the pace of change. They wanted to do more to stay ahead. Having a mobile website was table stakes now. So SFCC needed an architecture that was more flexible than SiteGen, and more mobile friendly. SiteGenesis, the old architecture, just wasn’t built for teams who want to tweak a cart one week, redesign the homepage the next, and roll out Apple Pay without crossing their fingers every time they push code. Too many tied-together scripts, too much legacy debris.
SFRA was Salesforce’s answer to both the technical and commercial headaches. They looked at two major pain points; a need for real mobile performance, and a requirement for modularity. Then, they rewrote the blueprint. It was still what we now call monolithic but it was a leap forward in the way information moved around SFCC and got to the user.
This isn’t just a change in code style. SFRA brought:
Deploying any change used to mean crossing your fingers and hoping three other things didn’t break. With SFRA, you’re dealing with modules: change the cart, and the homepage doesn’t fall over. Want to swap a payment provider? You don’t have to undo half the checkout flow.
Most teams believed they would see faster build times, easier onboarding for new engineers, and a long-term drop in maintenance costs. It’s not zero-maintenance, it never is, but you're not weighed down by years of tech debt with every new sprint. It didn’t always quite work out as neatly as that. And the giant SIs charged a lot of money for not a whole lot of actual work to get there. But hey, it’s progress.
If you’re an e-commerce leader today and your site hasn’t at least moved to SFRA, that last point was probably key. Like many advances in Salesforce land it was weighed down by the greed of big system integrators who saw an opportunity to get replatform money for upgrade workloads.
So, often because of the time projects took and the cost of getting help, up to 50% of SFCC customers did not upgrade. (There are no official numbers but anecdotally that’s not far off.)
Nobody wins by sticking with tech whose best years are behind it. Speed is measurable. Cost of ownership is never going down on old stacks. Customer expectations get higher each season, not lower. In its day SFRA gave you a modern toolset for an environment where agility mattered more than keeping the lights on. But it’s 2018 technology. It works today - there are some great highly performant SFRA sites out there - but doesn’t offer any forward looking benefits at all. It won’t help you develop skills in managing your data, it won;t help you move faster on content, it won’t help you escape the cadence of Salesforce on product updates. It’s better than SiteGenesis. But that was 2018’s problem, not 2025’s. And truthfully, building SFRA in 2025 is just wastefully expensive. Though the absolute cost has come down a lot in the past few years, you will be upgrading to composable in 2027 so you are just throwing money down the drain..
No. SFRA is an entire reference architecture. But SFCC has had solid APIs available to it forever. If you are on SiteGen today you can build some of the elements of SFRA architecture into your SFCC backend - hooks and custom endpoints, even controllers - that mean you can drive your composable site without a huge back-end re-architecture in the short term. In fact one of the arguments for composable is the opportunity it gives teams to upgrade the back-end themselves over time in a controlled way and improve the way they have constructed Salesforce with much lower risk to the production site. And the time to do that - now they aren’t dealing with merchant requests and technical spinning plates all day long.
SFRA was Salesforce’s commitment to building e-commerce sites that could survive and thrive in 2018 and to its credit it was the best choice for an upgrade through 2022 if you could afford it. But its time has come and gone. And a composable storefront allows you to skip comfortably past SFRA right to a modern (for now!) stack. Salesforce is investing heaviest now in composable SFCC. The price of a build is six figures rather than seven. And it sets up SiteGen customers to take advantage of AI innovations as they emerge from Salesforce and beyond.
Modern SFCC customers have to move faster than SFRA and templated architectures will allow them. In 2026 you will be glad you took the plunge and skipped past SFRA to composable storefront.
If you need the gritty details, Let’s Talk.
5 min read
•
July 15, 2025
Composable
Ecommerce
How Does Composable Help Marketers and Merchants
Marketers and merchandisers in enterprise retail are often stuck in a weird paradox: they have powerful ideas, agile teams, and massive goals, but a tech stack that moves like it's 2012. If launching a promo takes 3 JIRA tickets and 2 weeks of dev time, you're not just behind, you're bleeding money.
Enter composable commerce: a modular, API-first approach to building digital storefronts. While it sounds like a developer’s dream (and it is), the biggest wins actually show up for marketers and merchants.
Here’s how.
Composable means your frontend is decoupled from your backend. So when merch or marketing wants to:
...they can do it without dev involvement (or with minimal support). Teams can use low-code/no-code tools integrated into the stack (like CMSs or visual merch tools) to make changes in hours, not weeks. And dev teams, before you get too upset, these guys have been using tag managers and personalization tools behind your back to do things they shouldn't for about 10 years now. This is better-safer-transparenter than that.
Result: Faster go-to-market, more A/B testing, more wins.
Legacy monoliths often treat personalization like a bolt-on feature, not a core capability. Composable stacks let you plug in best-in-class personalization engines (we have hard-core expertise in or Dynamic Yield) that actually talk to your content and commerce layers in real-time.
Marketers can then:
Now, it better be built correctly by a partner who knows what they are doing. (cough). And that partner better be in the weeds with your team on what it has to do where (double cough). And you better be willing to out some work into making it work rather than think it automagically improves conversions (whooping cough). But a composable architecture does unlock all this.
Result: Better CX, higher conversion rates, more data to refine.
Composable gives you control over your frontend experience. Sure you have, like templates with like Bootstrap n stuff that you can play with. But repeat after me - ISML is DISML. With composable you are a world of React and Typescript and kittens. You get to control how the site looks, feels, and behaves instead of being locked into the templates someone thought were state of the art back in 2014.
This means your brand team can:
…without getting a “that’s not possible with our CMS” reply from IT.
Result: Experience-driven commerce, not catalog-driven commerce.
Move fast and break stuff they say. Yeah, great advice for a 20 year old building an app no one wil likely ever have to use. We don;t get that luxury. Marketers and merchandisers are constantly caught between "move fast" and "absolutely don’t break stuff."
Composable gives us a middle ground:
Result: Less stress, more autonomy, more velocity, more control.
{{banner}}
Worried about an old school Big Bang launch of composable? Don't be. You can put a full composable site out to a subset of users for as long as you want before you have to commit ? Don’t be. Most enterprise teams go with a split launch - maybe 5% of users to start. They iron out any kinks. Then when they realize how much the ROI will be if they switch over like right now, they switch.
You can go incremental of course.
You can plug in a headless CMS (like Contenstack or Amplience), run it headlessly within your legacy stack for a while, and prove ROI before ripping anything out. Or un composable with a new CMS in one region for six months to give yourselves some experience of both before rolling out globally.
Result: Low risk, high reward — easy to minimize risk and you keep IT on your side.
In a world where campaigns move at the speed of culture and conversion windows last minutes, composable lets marketers and merchandisers do what they do best: create, launch, measure, and optimize without waiting for devs, approvals, or outdated systems to catch up.
5 min read
•
August 8, 2025
Salesforce
Ecommerce
Why Salesforce Commerce Cloud Is Still the Best Enterprise eCommerce Platform
Salesforce Commerce Cloud (SFCC) has evolved from its Demandware roots into a modern enterprise platform capable of powering fully composable, headless storefronts. Today, leading brands pair SFCC’s robust backend with modern front-end frameworks like Next.js and Vercel and headless CMS platforms such as Contentstack or Amplience to unlock faster performance, better developer agility, and richer customer experiences.
64Labs is the global leader in composable SFCC builds, delivering projects for enterprise retailers such as Horizon Hobby, Moncler, Sweaty Betty, and Duluth Trading all with measurable performance and revenue gains.
Salesforce acquired Demandware in 2016, gaining one of the most mature cloud-native commerce platforms on the market. At a time when competitors still relied on on-prem or heavily customised systems, Demandware offered scalability without infrastructure headaches.
While its CMS and search were limited in those early years, its stability, global readiness, and proven operational model made it the Porsche of eCommerce platforms - engineered for performance, enduring in design, and able to stay relevant as the world caught up.
At its core, SFCC remains a stable, scalable SaaS commerce engine. It handles:
The real shift in recent years? SFCC now fits seamlessly into composable architectures, enabling brands to swap in best-of-breed tools while retaining a bulletproof commerce core.
This evolution lets enterprise teams:
Salesforce Commerce Cloud shines when:
When paired with a composable approach, SFCC gives brands backend stability and frontend freedom - the best of both worlds.
SFCC’s native CMS and search still lag behind best-in-class options. That’s why most of our composable builds integrate platforms like Amplience or Contentstack for content, and tools like Algolia for search.
Pricing can be a sticking point, but in 2025, negotiation flexibility is far greater - especially if you have the right partner guiding your roadmap.
Salesforce Commerce Cloud has come a long way since the Demandware days. It’s no longer just a managed backend for templated storefronts. It’s evolving into a flexible foundation for composable architectures, with room to plug in modern tools and scale globally.
For teams who need stability but don’t want to sacrifice flexibility, SFCC remains one of the few options that can support both. But to unlock its full potential, the architecture around it - including frontend, CMS, and integrations - needs to reflect modern composable thinking. And to get that, you need a partner that really lives this stuff. 64labs is far and away the leader in composable on SFCC. If you aren't being asked to bring us into conversations about your composable roadmap in some form someone isn't doing their job.
Thinking about building a composable storefront on Salesforce Commerce Cloud? We’ve helped some of the biggest names do it right. Let’s talk.