SFCC B2C vs Headless Commerce: When to Go Headless

Every SFCC engagement I walk into these days has the same question on the table: should we go headless? The short answer is: sometimes yes, often no, and always 'it depends in ways that will take three workshops to untangle.'

What 'headless' actually means on SFCC

SFCC B2C gives you three primary frontend delivery options: SFRA (Storefront Reference Architecture), PWA Kit, or a fully custom frontend consuming OCAPI/SCAPI. SFRA is the battle-tested MPA approach — server-rendered, cartridge-based, fast to launch. PWA Kit is Salesforce's own headless React framework, giving you SPA-style UX with React on top of the SCAPI layer.

When most people say 'headless on SFCC' they mean either PWA Kit, or a custom React/Vue/Next.js frontend hitting SCAPI. Both decouple the presentation layer from the platform, giving your frontend team full control over the UX without being constrained by cartridge templates.

When to go headless

• You have a dedicated frontend team fluent in React — headless requires frontend ownership that SFRA doesn't. If you're relying on SFCC cartridge developers to build your React components, you'll hit a wall fast.
• You need sub-2-second page loads at scale — a well-optimised PWA Kit storefront with edge caching will outperform SFRA on perceived performance metrics every time.
• You're delivering the same commerce data across multiple touchpoints (web, mobile app, kiosk, voice) — a headless API layer genuinely pays off when you have more than one consumer.
• Your brand team needs pixel-perfect control that SFRA templates make difficult — headless removes the 'but the cartridge doesn't support that layout' conversation entirely.

When NOT to go headless

• You're under timeline pressure — SFRA can go live in 5-7 months; a solid headless build realistically needs 10-14 months minimum for a complex storefront.
• Your team is small or primarily SFCC platform developers — building and maintaining a React frontend is a separate discipline with its own hiring, tooling, and deployment concerns.
• Your requirements are standard B2C commerce — product listing, cart, checkout, account — without exotic UX needs. SFRA handles this cleanly and maintainably.
• Budget is constrained — headless means higher upfront build cost and ongoing frontend infrastructure (CDN, edge functions, CI/CD for the frontend layer).

The decision framework I use

I ask four questions: (1) Do you have, or can you hire, a frontend team that owns React end-to-end? (2) Are you launching on more than one frontend channel in year one? (3) Is your performance bar higher than what SFRA with a CDN delivers? (4) Is your timeline 12+ months? If you answer yes to three or more: headless is worth the cost. Two or fewer: start with SFRA and plan a migration when your requirements genuinely demand it.

The right architecture is the one your team can ship, maintain, and evolve confidently. That question should always come before the technology conversation.