Building a Composable Storefront: Prerequisites, Setup, and Common Pitfalls

SAP’s documentation for the Composable Storefront is solid. The problem is it assumes you already know Angular, understand OCC APIs, and have a Commerce Cloud backend humming away in the background. In the real world, teams hit issues that aren’t in the setup guide. Mismatched API versions. SSR config that doesn’t work. CMS component mappings that silently fail.

This covers the actual prerequisites, the setup process as it works in practice, and the mistakes that slow down every second implementation we see.

TL;DR: Building a Composable Storefront requires Angular CLI, Node.js (LTS), a Commerce Cloud backend with OCC APIs enabled, and Angular/TypeScript expertise. Setup takes 1–2 days for basic, 4–8 weeks for production-ready. Mobile commerce reached $2.07 trillion in 2024 — 57% of total e-commerce (Oberlo, 2025). Your storefront needs to work on mobile from day one.

What Are the Prerequisites?

Gartner has named SAP a Leader in Digital Commerce for 11 consecutive years (SAP News, 2025). But the platform investment means nothing if the storefront is a mess. Getting this part right matters.

Technical prerequisites:

• Node.js on LTS (check SAP’s compatibility matrix)
• Angular CLI matching your target storefront version
• A running Commerce Cloud instance with OCC APIs accessible
• OCC API endpoints enabled for products, cart, checkout, CMS, and user APIs

Team prerequisites:

• Angular, TypeScript, and RxJS experience (non-negotiable, seriously)
• Access to Commerce Cloud Backoffice for CMS configuration
• Understanding of OCC API authentication (OAuth 2.0)

I can’t stress the team part enough. We’ve walked into projects where the team had React experience and figured Angular would be close enough. It isn’t. RxJS alone is a different mental model. Budget time for that learning curve or hire people who already have it.

How Does the Setup Process Work?

Global e-commerce hit $6.334 trillion in 2024 (eMarketer, 2024). Your setup determines how fast you start capturing some of that.

Step 1: Scaffold the project. Use Angular CLI with SAP’s schematics to wire up the project structure and install dependencies. Crisp and straightforward.

Step 2: Configure backend connection. Point at your Commerce Cloud OCC API URL. Configure base site, language, and currency. Mismatched API versions cause the most grief here. Check the compatibility matrix before you write a single line of code.

Step 3: Set up CMS mapping. Map CMS component types to Angular components. SAP provides defaults for the standard ones. Custom CMS components need custom mappings. No shortcuts.

Step 4: Configure SSR. Set up Angular Universal with a Node.js Express server. Optional for development, but you need it for production (SEO and performance).

Step 5: Customise and brand. Override default styles, extend components, add custom CMS components, configure the checkout flow. This is where it starts feeling like your store instead of a demo.

What Are the Most Common Setup Mistakes?

Forrester predicts more than half of large B2B transactions ($1M+) will go through digital self-serve channels by 2025 (Forrester, 2024). Setup mistakes have real revenue impact.

API version mismatch. The storefront and backend must be on compatible versions. I’ve seen teams burn a full sprint figuring out why nothing works, only to discover the versions don’t match. Check the compatibility matrix first. Always.

Skipping SSR in development. SSR affects performance, social media previews, and load behaviour. Set it up from the start. Retrofitting it later is painful and you’ll wonder why you didn’t just do it in week one.

Hardcoding instead of using CMS. Use CMS components from the beginning. Hardcoded content creates deployment dependencies for what should be simple content changes. Your marketing team will hate you for it.

Ignoring lazy loading. Review which modules load eagerly versus lazily. Checkout modules shouldn’t load on the homepage. Prima vista it seems minor, but on mobile it compounds fast.

Not planning mobile-first. Custom components need explicit mobile testing. Build for mobile and expand to desktop, not the other way round. $2.07 trillion in mobile commerce says so.

How Should You Structure Your Project?

Keep customisations separate from SAP’s code. Clean boundaries now save you pain on every upgrade:

• Feature modules for custom functionality in Angular feature modules
• Component overrides using dependency injection to replace SAP components
• Shared modules for common utilities and services across features
• Style overrides via CSS custom properties and component-scoped styles

This isn’t just good practice. It’s survival. SAP ships storefront updates regularly, and if your custom code is tangled into their base code, every upgrade becomes a multi-week project. Keep it clean.

For a deeper architecture discussion, see our storefront architecture guide. For migration from Accelerator, see the migration guide.

FAQ

How long does a basic setup take?

One to two days for a basic working storefront. Four to eight weeks for production-ready with custom branding, CMS components, and SSR.

Can I use it with a local Commerce Cloud instance?

Yes, but most teams use a cloud-hosted dev environment. Running Commerce Cloud locally needs 8GB+ RAM.

What’s the minimum Commerce Cloud version?

Commerce Cloud 1905 or later. For best support, use the latest (2211+). Check SAP’s compatibility matrix.

How do I handle multi-site setups?

The storefront supports multiple base sites from a single deployment, each with its own theme, language config, and CMS content. Neat if you’re running several brands off one codebase.

Do I need separate builds for B2B and B2C?

Not necessarily. Both B2B and B2C modules can live in the same build. Separate builds are cleaner if the experiences diverge a lot, but it’s a judgment call.