Hybris B2B vs B2C Accelerator: The Right Starting Point

What is an accelerator, and why is it a critical decision?

The accelerator is SAP Commerce's ready-made store skeleton: sample data models, order flows, payment/shipping integration points and frontend templates that shorten the distance from 'empty platform' to 'store' by months. Its criticality lies here: whether you start with the B2B or B2C accelerator, and how you customize it, determines not just the project's first month but the upgrade bill five years later. This article explains the real differences and the starting setup that never turns into regret.

B2B and B2C: the difference is the model, not cosmetics

The decision rule looks simple but is violated often in the field: if your business model contains account hierarchies, custom pricing and approval flows, do not try to patch B2B onto the B2C accelerator — those three capabilities exist at the model level in the B2B accelerator, and hand-building them becomes the project's most expensive surprise. The reverse also holds: buying the B2B accelerator for a purely B2C operation converts unused complexity into maintenance burden. If you are both (dealers + end consumers), in a multi-store setup each channel lives on its own accelerator base.

Customization strategy: staying upgradeable

The red flags from our health check article are born in accelerator customization style. The right setup is three rules: accelerator code is reference, not trunk — customization lives in your own extensions/addons; accelerator classes are never copied and edited in place; extension points are preferred — behavior changes happen through overridable bean definitions, event/interceptor mechanisms and configuration; the data model is extended with discipline — instead of raining attributes onto existing types, business-domain types are defined in their own extension. The reward is concrete: the conflict surface shrinks in platform upgrades, and 'how far did we deviate from the accelerator' remains a measurable question.

The frontend reality: accelerator storefront and composable

The accelerator's classic JSP storefront did the job for years; in today's implementations the frontend decision is made separately: SAP's composable storefront (Spartacus-derived, Angular-based) or your own React/Next.js layer on the OCC APIs as we built in our headless article. Our practical guidance: in new projects, separate the server-side accelerator (business logic, flows, integrations) from a headless frontend; the classic storefront remains legitimate as the starting point of gradual migration in existing setups. What is critical is that business logic never leaks into the frontend layer — the commerce core must stay in place even when the frontend changes (the platform version of the boundary principle from our BFF article).

The first 90 days: from skeleton to business value

The healthy phase order with an accelerator: foundation (accelerator + your own extension skeleton + CI/CD pipeline + environment strategy — first-week deliverables); model adaptation (catalog structure, pricing model, B2B account/role hierarchy — in workshops with the business); the integration backbone (ERP price/stock/receivables flows — S/4HANA integration is the next article's own topic); and flow customization (checkout, approval chains, quick-order adaptations). The logic of this order is risk management: the most uncertain and most expensive area is integration; projects that leave it last meet ERP reality in go-live week.

Business impact: the balance between speed and debt

The accelerator's promise is speed, and it is real — but speed comes in two kinds: first-demo speed and sustainable delivery speed. Copy-and-edit accelerates the first demo and slows every change in year two; disciplined extension looks slightly slower in the first weeks and delivers at constant speed for years. The commercial reading is in upgrade cost: in cleanly built projects a version upgrade is a routine maintenance item; in dirty ones, every upgrade is a mini rewrite. Your starting decisions are the purchase of one of those two futures.

Frequently asked questions

Does starting from scratch, without the accelerator, make sense?

Rarely: the platform's value is in its ready commerce model and flows; starting from zero discards that value. The exception is a business model fundamentally at odds with accelerator assumptions — in which case the 'custom build' row of our platform selection article deserves re-evaluation.

We started B2C and B2B needs emerged; what now?

Stop before patching: enabling the B2B accelerator's account/pricing/approval model as a separate store or site sharing the common core is almost always cheaper than hand-building B2B on top of B2C. Design the transition together with a cleanup of your existing customizations.

How do accelerator and platform versions relate?

The accelerator is versioned with the platform; hence 'how much you touched the accelerator' is the main multiplier of your upgrade cost. A deviation inventory (which accelerator part, why, how changed) is the input to the upgrade rehearsal.

Where does a mobile app fit in this setup?

On the OCC APIs: mobile is one of the headless frontends and uses the same commerce core. If separate business logic has started accumulating for mobile, that is a boundary-violation alarm.

Accelerator starting checklist

1. B2B/B2C decision made with a business model inventory (accounts, pricing, approvals)

2. Customization in your own extensions/addons; accelerator never copied

3. Extension points preferred; deviation inventory maintained

4. Frontend decision made separately; business logic kept in the core

5. First-90-day phases: foundation → model → integration → flows

6. ERP integration pulled into an early phase; no go-live surprises

7. Upgrade rehearsal and deviation report defined in the process

SSH Yazılım builds accelerator selection, implementation architecture and upgradeable customization strategy for SAP Commerce projects end to end. Let us make the right start together.