Core Laravel Package

Product Decisions This Supports

• Build vs. buy for the commerce core. This is the artifact behind the question "do we own our checkout, catalog, pricing, and promotions engine, or rent it?" shopware/core is the buy option with source access — MIT licensed, self-hosted, no GMV rev-share.
• Architecture direction: headless vs. coupled. Core is a commerce engine, not a storefront. Choosing it enables a composable model (custom frontend or third-party) while keeping order/pricing logic server-side.
• Extensibility strategy: plugin/app vs. fork. The core's public surface (DAL, extension system, events) determines which roadmap features are a two-week plugin and which are a quarter-long fork. That ratio drives roadmap sequencing.
• B2B and internationalization scope. Multi-currency, rule-based pricing, customer groups, and promotion engine ship in core — decide to configure these rather than build them.
• Data ownership and lock-in posture. Doctrine entities and the DAL mean your schema is Shopware's schema. This feeds decisions on migration cost, analytics/warehouse design, and data residency.
• TCO modeling. MIT license shifts cost from per-transaction fees to infrastructure plus specialized headcount — a direct input to the platform P&L.

One flag for the record: this is not a Laravel package. It is the Symfony/Doctrine core of Shopware 6, published as a read-only subtree split of shopware/platform. The 59 stars and 0 dependents reflect the split, not adoption — do not use them as a quality or traction signal. Evaluate against the parent repository and the plugin/agency ecosystem instead.

When to Consider This Package

Adopt when:

• You need a self-hosted, permissively licensed commerce engine with real depth — B2B pricing, promotions, multi-storefront, CMS — and are prepared to operate it.
• You have, or will hire, Symfony/Doctrine engineers. No Eloquent, no Blade, different DI container and HTTP kernel. A Laravel-native team pays a real, ongoing tax here.
• You intend to run the full platform (shopware/platform or the production template) and extend via plugins/apps. Depend on shopware/core alone only if you are deliberately supplying the application shell, admin, and configuration yourself — that path is high-effort and thinly documented.

Look elsewhere when:

• Managed operations are acceptable. Shopify, commercetools, or BigCommerce trade control for headcount; be explicit that this is the trade.
• The team is Laravel-native and staying that way. Lunar, Bagisto, or Aimeos keep you in familiar idioms.
• You need a catalog and cart, not a platform. Shopware's surface area is large; small storefronts pay for capabilities they never use.
• The org cannot absorb major-version migrations. Shopware 5→6 was effectively a rewrite. Assume 6.x→7 is a project, not a patch.
• Hiring depth matters. Shopware talent is far scarcer than Laravel or Node commerce talent; that scarcity is a roadmap risk, not an HR detail.

How to Pitch It (Stakeholders)

To executives: We can own our commerce stack outright under an MIT license — no revenue share, no per-order tax. The cost moves from GMV percentages to infrastructure plus specialized engineers, and we take on uptime and upgrade responsibility. This is a multi-year platform commitment, not a dependency swap.

To engineering: Mature Symfony/Doctrine codebase with a real commerce domain model — orders, carts, pricing rules, DAL — that we do not have to invent. The price is a hard dependency on Shopware's release cadence and conventions, and customization must go through plugins and apps rather than core forks.

The risk to name out loud: reversibility is low. Once catalog and order data live in Shopware's schema, exit is a migration project. Treat this as a platform bet.

The ask: not adoption — a timeboxed 3–4 week spike. Stand up the production template, build one representative B2B flow as a plugin, and measure the team's actual ramp against Symfony and the DAL. Commit or walk based on that evidence.