What we use Shopware for
The typical case is a wholesaler or manufacturer who wants to give existing customers a way to order. Prices are rarely public there: every customer sees their own terms, often with volume tiers and special prices at item level. Then come the organisational structures — one head office, several branches, requisitioners with a budget and buyers with approval rights. Treat B2B as D2C with a login in front of it and you build a handsome catalogue that nobody uses.
The second common case is connecting to the customer's procurement. Large buyers do not order in a browser, they order out of their SAP, Onventis or Coupa system. For that we implement OCI punch-out and cXML: the basket is assembled in the shop and travels back into the procurement system, where the internal approval runs. Alongside this we do classic D2C projects on Shopware 6, usually when the range, the variants or the payment methods go beyond what a WooCommerce setup sensibly carries.
How we work with Shopware 6
Shopware 6 is a Symfony application. Whatever peculiarities a project brings with it are built as our own plugin or app — with their own entities, services and Twig extensions through the theme layer. Nothing is changed in the core. That sounds obvious, but it is not: core hacks are the most common reason a shop trails several versions behind and nobody wants to touch the update.
We map pricing logic with the Rule Builder for as long as it can be described with what the system provides; where it gets more complex, a custom price rule implementation is added. For search and load we use Elasticsearch and Redis where data volume and traffic justify it — not as standard equipment. Headless requirements run through the Store API. Deployment, staging and updates belong to the project, not to the special requests: a shop that is only current at launch is a security problem on a delay.
Limits: when Shopware is the wrong choice
Shopware 6 is not a lightweight system. For a shop with a handful of items, one price per item and no ERP connection, the stack is oversized — there we advise WooCommerce, especially when WordPress is running anyway. For content sites with a few products attached, the running effort rarely pays off either. Running effort here means updates, a test environment, monitoring, plugin maintenance, certificates.
The second limit runs at the marketplace. Anyone who needs third-party sellers, commission accounting and separate payouts is working against the data model; a platform with a multi-vendor core is the more honest route. And if a Shopware 5 shop is still running: Shopware 5 reached end of life at the end of July 2024, and security updates are now only available commercially through a third-party provider. An upgrade is technically a rebuild with a data transfer, not a version jump. We say so in advance, because otherwise the budget tips over mid-project.