Shopware plugin:buy it orhave it built?

Whether you should buy a Shopware plugin or commission Shopware plugin development comes down to one question: does the Store extension fit your process, or would you have to bend your process to fit the extension? If it fits, the Store is usually the faster route. If your shop runs on Shopware Cloud as SaaS, apps are your only option anyway, because Shopware says plugins are not supported there. And if you only need to change a lot of records once, you often need no extension at all, just a tested script that uses the Admin API.

Nikolai Schöbel and Jeremias Burger

Co-founders of Scalableloops GmbH. Nikolai Schöbel leads online marketing and AI strategy, Jeremias Burger the AI architecture. Both build AI systems and train teams on them in their own agency work.

Shopware app vs plugin: what is the difference?

Shopware 6 has two kinds of extensions. Plugins run in the process of the Shopware core, react to events, execute their own code and have direct access to the database. Apps run outside the core, are notified of events via webhooks and work with the shop's data through the Admin API.

That defines the limits. An app cannot change the database structure and cannot register internal routes or console commands. In return it is more loosely coupled to the Shopware version and runs in the cloud as well as in a self-hosted shop. Since Shopware 6.4.8.0, apps can also run logic inside Shopware using App Scripts, in a sandboxed environment.

In practice: if the job is exchanging data with an external system such as an ERP, a PIM or shipping, an app is often the more future-proof choice. If the extension has to reach deep into checkout, price calculation or the data model, the route usually leads to a plugin, provided your shop allows it.

What does a Store plugin cost, and what does a custom one cost?

Since 28 December 2023, the Shopware Store has only offered rental licences, billed monthly or yearly. The old purchase option with an update subscription is gone. This matters for your budget: when the rental period ends, the shop loses the right to use the extension. A Store extension is therefore a running cost for as long as you need the feature.

A custom plugin costs development once and maintenance after that. The amount depends less on the number of features than on a few drivers that agencies consistently name: business complexity, the number of connected systems such as ERP or CRM, custom interfaces in the Administration or storefront, performance and security requirements, the scope of testing and how flexibly the solution should be extendable later.

The calculation tips at one point: if a Store extension has to be customised before it fits, you pay rent and customisation. And the customisation depends on third-party code that may look different after the provider's next update. That is why only an estimate broken down by components is serious. A lump sum without a breakdown does not tell you what you are paying for.

When is an Admin API script enough instead of a plugin?

Not every task needs permanent code in the shop. According to Shopware, the Admin API is the interface for integrations, automation, data synchronisation, imports and exports, and it offers read and write access to every entity. For bulk changes there is also the sync endpoint, which creates or updates many records in a single request.

An example from our work for a pram manufacturer: 23 product variants needed an EAN for Google Shopping. In the user interface, the editing stopped after two entries with a timeout, and the CSV import reported errors. We set the remaining 21 through the Admin API. We first read the existing data via the Admin API, then wrote only the one target field and afterwards checked every record. No plugin was needed, and no additional code was left in the shop for someone to maintain during updates.

The limit is clear: a script is suitable for one-off or rare changes with a proper check afterwards. If a rule has to apply permanently to every order, it belongs in an app or a plugin.

What belongs in a briefing for a Shopware developer?

A good briefing affects effort and outcome more than the choice of developer. Statements like "we need special logic in the checkout" are not enough. These points should be on the table before the first estimate:

1. 01

   Process

   Step 1

   Who clicks what, in which order, with which data, and what should be different afterwards.

2. 02

   Rules and exceptions

   Step 2

   When does the logic apply, for which customer groups or products, which special cases exist, what happens on errors.

3. 03

   Connected systems

   Step 3

   ERP, PIM, CRM, shipping: which data flows in which direction, and how often.

4. 04

   Hosting and version

   Step 4

   Self-hosted, PaaS or SaaS, current Shopware version, plan. This decides between plugin and app.

5. 05

   Alternatives checked

   Step 5

   Which Store extensions you have looked at and where they fall short.

6. 06

   Acceptance and maintenance

   Step 6

   How you will know it works, and who adapts the extension when Shopware updates.