Shopware Agency · Plugin development

For us, a plugin isn't a template override with a bit of PHP but a proper extension with clear boundaries. Typical building blocks are custom entities with migrations when your model needs data Shopware doesn't know: approval workflows, customer hierarchies, project prices or configuration data from the ERP. On top of that come administration modules in Vue.js, so your team can maintain this data themselves without asking us.

On the storefront side we add Twig components, custom pages and checkout steps that fit into the existing theme. For external connections we develop API endpoints based on the Store API and the Admin API, for example for punch-out systems, pricing engines or shipping providers. How we build larger integrations is shown on the Shopware interfaces page.

Shopware plugin development is part of our Shopware development, not a standalone offer. A plugin that calculates prices has to fit the ERP sync, an approval workflow has to fit the checkout. That's why, before building, we check where the logic belongs: in a plugin, in an interface or in a Rule Builder and Flow Builder configuration that needs no code at all.

Shopware offers two ways to extend a shop. A classic plugin runs inside the Shopware instance in the Symfony kernel, has direct access to services and the database and can adapt any part of the system. That's exactly why it's only possible in self-hosted installations: Shopware Cloud doesn't run third-party code in the shop's process, so classic plugins aren't supported there.

An app built on the Shopware app system runs outside the shop instance. It registers via a manifest, is notified of events through webhooks and works with the shop via the Admin API. The app's code lives on its own server, run by you or by us. Even so, an app can bring admin modules, custom entities, custom fields and payment methods, and with app scripts, synchronous logic such as cart rules runs in a sandbox directly in the shop. Apps work in the cloud and self-hosted, plugins only self-hosted.

So the choice depends first on the operating model. If you use Shopware Cloud or want to keep the option of switching, you need an app. If you stay self-hosted and need to go deep into services, checkout or the data model, a plugin is often faster and needs less infrastructure. We build both and tell you up front which route fits your setup.

It starts with the question of whether you need the plugin at all. We check whether Rule Builder, Flow Builder or an existing marketplace plugin already covers the requirement. Only if that's not enough do we describe the scope: which data, which admin views, which storefront elements, which interfaces. The result is an effort estimate that names risks instead of hiding them.

During delivery we work in short iterations, so you see early on whether the logic really matches your model. The plugin is built in your repository, every change goes through code review, and unit and integration tests run in the pipeline. You can check interim versions on a staging environment with your real data before anything moves toward live.

The release is a documented step: migrations run in a controlled way, the configuration is described, and a README and changelog are included. Afterwards we take over maintenance and update testing if you like, so the plugin keeps running with the next Shopware release. And because the code belongs to you, you can take over further development yourself at any time.