Shopware plugin:buy it orhave it built?

Process

When is an extension from the Shopware Store enough for your process?

Read the description of a Shopware Store extension against your process, not against a feature list. A bundle plugin that discounts bundles in the cart will not help you if your bundle has to reach your ERP as a separate item number. So start with a description in a few sentences: who does what, in which order, with which data, and what should be different afterwards.

For standard tasks the Store is strong. Payment methods, shipping carriers, newsletter connections and reviews are maintained there by providers whose business depends on exactly that integration. Before publication, every extension goes through an automated code check with PHPStan and SonarQube and a manual review of security, coding standards, usability and function. That does not replace your own testing, but it lowers the risk compared with unreviewed code.

Before you buy or commission anything, check what Shopware already offers. You can create custom fields for products or categories in the Administration under Settings, System, Custom fields, without writing a line of code. For a lot of additional information, that is already enough.

Technology

Shopware app vs plugin? What matters is where the code runs

Shopware 6 has two kinds of extensions, and comparing Shopware app vs plugin comes down mainly to where the code runs. 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.

Hosting

Shopware Cloud and the Community Edition fair usage policy decide which plugin your shop can use

Whether your shop runs on Shopware Cloud often decides whether a plugin is an option at all. Shopware runs two cloud models: SaaS, where Shopware takes care of hosting and updates entirely, and PaaS, where Shopware manages the infrastructure and you manage the application. According to the developer documentation, customisation on SaaS is only possible through apps, because plugins are not supported in the cloud due to their direct access to the process and the database. Self-hosted shops allow both.

A second point concerns the free Community Edition. A fair usage policy has applied since 24 March 2025: companies whose shop generates more than one million euros in annual revenue need one of the Rise, Evolve or Beyond plans to keep access to the Shopware Account and the Shopware Store. The open source licence itself is unchanged. If you are close to that threshold, clarify this before buying a Store extension.

Also check whether your plan already includes the feature. Shopware offers B2B Components and Advanced Search from the Evolve plan upwards, not in Rise. If you are thinking of having such a feature rebuilt, work out the cost of switching plans first.

Cost

How much will a Shopware plugin cost as a rental licence or a custom build?

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.

Updates

Why did plugins with Administration components need separate versions for the Shopware 6.7 update?

Whether you use a custom plugin or an extension from the Shopware Store, the same classification applies: Shopware distinguishes between major, minor and patch versions. Minor versions are released monthly and, according to Shopware, generally contain no changes that break existing code. Major versions, on the other hand, contain breaking changes, for example when moving to new versions of Symfony or Vue.js. Every extension has to state explicitly which Shopware versions it supports.

Shopware 6.7 showed how big that step can be: the Administration build moved from Webpack to Vite, the compatibility layer for Vue 2 was dropped and the framework jumped to Symfony 7. Plugins with components in the Administration therefore needed separate versions for 6.6 and 6.7. Shopware has announced the next major version, 6.8, for 2027, and extended support for 6.6 continues until then.

For your decision this means: with a Store extension, the provider handles the adjustments for as long as they maintain it. With a custom plugin, the work lies with you or your developer, but you can plan it. Test every major update in a staging environment first, whichever route you chose.

Case study

For bulk changes, a script via the Shopware Admin API is usually enough

Not every task needs permanent code in the shop, and the Shopware Admin API covers a lot of it. 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.

Comparison

Who carries the responsibility in Shopware extension development, and where each route may run

Shopware Store extensions, custom apps, custom plugins and scripts differ less in price than in who carries the responsibility and where they are allowed to run.

Briefing

Before you commission custom Shopware plugin development, a briefing sets effort and outcome

A good briefing affects the effort and outcome of custom Shopware plugin development 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. Step 1ProcessWho clicks what, in which order, with which data, and what should be different afterwards.
2. Step 2Rules and exceptionsWhen does the logic apply, for which customer groups or products, which special cases exist, what happens on errors.
3. Step 3Connected systemsERP, PIM, CRM, shipping: which data flows in which direction, and how often.
4. Step 4Hosting and versionSelf-hosted, PaaS or SaaS, current Shopware version, plan. This decides between plugin and app.
5. Step 5Alternatives checkedWhich Store extensions you have looked at and where they fall short.
6. Step 6Acceptance and maintenanceHow you will know it works, and who adapts the extension when Shopware updates.

In one hour

Decide in one hour whether to rent a Store extension or commission Shopware plugin development

1. 01Your process in a few sentencesWho does what, in which order, with which data. Then search the Store for the purpose, not the name, and read every description against your sentences.
2. 02Check hosting, version and planWhere does the shop run, which Shopware version and which plan are active, is the feature already included, and does the fair usage policy affect you.
3. 03Decide and get an estimateIf a Store extension matches almost all of your sentences, take it. If it matches only a few, have an app or a plugin built, with an estimate broken down by components and a plan for updates.