Every new Salesforce B2C Commerce (formerly Commerce Cloud / Demandware) project starts with the same architectural fork: stay on SFRA, or go headless with PWA Kit / composable storefront? It’s one of the highest-leverage decisions on the project, because it shapes cost, hiring, time-to-market, and performance for years. Here’s how I reason about it.
The two options in one paragraph each
SFRA (Storefront Reference Architecture) is the traditional, server-rendered storefront. The rendering, business logic, and templating all live inside B2C Commerce, built on controllers, ISML templates, and the platform’s cartridge model. It’s mature, well-documented, and the whole storefront lives in one place.
Headless / Composable (PWA Kit + SCAPI) decouples the frontend from the backend. Your storefront is a React application (PWA Kit, or your own) talking to B2C Commerce through the Salesforce Commerce API (SCAPI) and headless APIs. The commerce engine stays; the presentation layer becomes an independent app you host and deploy separately.
The decision factors that actually matter
Team and skills
- SFRA needs developers comfortable with the Salesforce B2C Commerce platform (ISML, cartridges, the B2C dev model).
- Headless needs modern JavaScript/React engineers plus someone who understands SCAPI. If your team (or your talent market) is full-stack JS, headless lowers the hiring barrier for the frontend.
Time-to-market
- SFRA is faster to launch: you start from a working reference storefront and customize.
- Headless has a higher upfront build cost — you’re assembling a storefront app — but can be faster to iterate on afterward.
Performance and UX
- Headless / PWA shines for rich, app-like, mobile-first experiences and fine-grained control over Core Web Vitals.
- SFRA delivers solid, conventional e-commerce UX with less engineering effort, but you’re more constrained by the platform’s rendering.
Complexity and operations
- SFRA = one thing to run, inside the platform.
- Headless = more moving parts: a separately hosted frontend, API contracts, caching strategy, and its own CI/CD. More power, more operational surface.
Cost
- SFRA: lower initial build, potentially more constrained later.
- Headless: higher initial investment, more flexibility and independence downstream. Total cost depends heavily on how much custom frontend you actually need.
My rule of thumb
Go SFRA when the storefront is fairly conventional, time-to-market matters, and the team is platform-centric. Go headless when the experience is a differentiator, you need app-like UX and independent frontend velocity, and you have (or want) a modern JS team.
Concretely:
- Mid-market brand, standard catalog, needs to launch this quarter → SFRA.
- Brand where the storefront experience is the product, mobile-first, multiple touchpoints → headless.
- Unsure / evolving → SFRA now, with clean separation of business logic, so a later move to headless is an evolution rather than a rewrite.
The trap: choosing headless for the wrong reason
“Headless” and “composable” are the fashionable words, and plenty of projects go there because it sounds modern, then pay for complexity they never use. Headless is a means to an end — app-like UX, frontend independence, omni-channel reuse of the commerce APIs. If none of those are real requirements, SFRA will get you to market faster and cheaper, and there’s no shame in it.
The architect’s job here isn’t to pick the trendy option. It’s to match the architecture to the experience ambition, the team, and the timeline — and to keep the business logic clean enough that today’s choice doesn’t lock out tomorrow’s.