App Bundle Laravel Package

Product Decisions This Supports

• App vs. plugin strategy. This package only matters on Shopware's App path (external service calling the shop's API) rather than the plugin path (PHP running inside the shop). Its existence makes the App path cheap enough to choose deliberately, which is the upstream decision everything else depends on.
• Build vs. buy on commodity plumbing. Registration handshake, credential persistence, webhook signature verification, install/update/uninstall lifecycle events — all commodity. Adopting a first-party, MIT-licensed bundle removes roughly 2–4 engineer-weeks and, more importantly, removes a bespoke security surface we'd otherwise own indefinitely.
• Time-to-market for App Store listing. Store review hinges on correct lifecycle handling and signed requests. Using the vendor's own bundle lowers review-failure risk and shortens the path to a listed app.
• Roadmap sequencing. With infrastructure de-risked, roadmap capacity shifts to merchant-facing differentiation (pricing rules, ERP sync, B2B workflows) instead of integration scaffolding.
• Portfolio standardization. If we ship more than one Shopware app, one bundle plus internal conventions gives us a single pattern to maintain and onboard against.
• Lock-in assessment. First-party ownership materially offsets the weak adoption signals (16 stars, 0 dependents). The bundle is a thin wrapper over shopware/app-php-sdk, so the credible fallback is the raw SDK — a low-blast-radius bet.

When to Consider This Package

Adopt when:

• Backend is PHP and already on Symfony (or we're willing to run a Symfony service alongside our main app).
• Target is Shopware 6.x and we're building an App, not a plugin.
• We need the full lifecycle: registration, secret rotation, signed webhook ingestion, install/uninstall cleanup.
• Team is small and we'd rather not own auth/signature code.
• Procurement friction must be zero (MIT, no license cost).

Look elsewhere when:

• The stack is Laravel. This is a Symfony bundle, not a Laravel package — it will not drop in. The correct play is shopware/app-php-sdk (framework-agnostic PSR) behind a ~1–2 day Laravel service provider. Do not budget this as a Composer install.
• Backend is Node/Go/other — use the corresponding official SDK or hand-roll.
• Scope is one or two webhooks with no lifecycle handling; a small handler is cheaper than the dependency.
• We need SLA-backed support, security backports, or long-term maintenance guarantees.
• We're building a plugin, or we want a hosted/no-code app platform instead of owning a backend.

Signals to monitor before committing: release cadence, whether bundle versions track Shopware major releases, and whether it stays in lockstep with SDK versions. Sparse dependents means few external users to surface breakage — we'd be an early-ish adopter and should pin versions.

How to Pitch It (Stakeholders)

For executives: This is a free, MIT-licensed, vendor-maintained Symfony bundle that handles the unglamorous, security-sensitive plumbing every Shopware app needs — registration, credential handling, signed webhooks, and install/uninstall lifecycle. It converts a multi-week integration chore into a few days of configuration, reduces the chance of failing App Store review, and carries low strategic commitment: it's a thin wrapper over Shopware's own PHP SDK, so we can walk away to the raw SDK if needed. Cost is engineering attention, not license fees.

For engineering: Treat it as wiring, not logic. It's a DI/route/middleware layer over shopware/app-php-sdk; there is no novel behavior to audit and no reason to fork it. Wrap it behind our own adapter interface so the framework and SDK are swappable, pin exact versions, and assume we own the upgrade path when Shopware ships a major. The bundle saves the boring 80% — we still own business logic, tenant isolation, and credential storage policy.

Risk framing: Low blast radius, moderate maintenance tail. The real risk isn't the dependency, it's assuming it's a Laravel package or assuming the vendor will absorb every future Shopware breaking change.