Shopware plugin and extension development

There is always one thing your shop has to do that Shopware does not do out of the box. A scanning flow for the warehouse, a discount structure that falls just outside the Rule Builder, an integration with no ready-made extension behind it. The question that follows is whether this warrants Shopware plugin development.

The answer is no more often than shop owners expect. And when it is yes, the way the plugin is built decides whether you are still happy with it two Shopware releases from now. Badly built customisation costs you nothing on the day it ships. It costs you at every update after that.

Kopie van Ontwerp zonder titel (12)

First question: does this need to be a plugin at all?

Before we write code, we check whether the problem is already solved. That is not modesty, it is arithmetic: every line of your own code is something you carry for years. We work through the same order every time.

  • Configuration. often already there, simply not set up.
  • Rule Builder. conditions around pricing, shipping and payment.
  • Flow Builder. automation around order states, email and webhooks.
  • Shopping Experiences. presentation and landing pages from the CMS layer.
  • Shopware Store. a maintained extension with an active vendor.
  • Integration layer. data between systems belongs in an iPaaS, as covered on Shopware integrations.

At that fifth step we look at release frequency and whether the vendor has kept pace with the 6.7 line. A well-maintained extension from the Store is almost always cheaper than your own version, because someone else keeps it compatible.

If something genuinely unique to your business is still left after that, a custom extension is the right route. That is what customisation should be: the part that sets you apart, not the part you had not configured yet.

Artboard-6-1536x1536

How we build, and what of ours is already in the Store

The first four points below are about the way of working that decides whether your plugin survives a Shopware update. The last three are extensions we built and published ourselves, so you can check what that looks like in practice.

Plugin, app or theme

The choice up front decides how deep you can reach and how much freedom you keep in hosting.

Built on the standards

Events, decorators, dependency injection and custom entities through the Data Abstraction Layer. Never a change in the core.

Upgrade path per release

At every minor release we check the extensions we maintain for deprecations and changed interfaces.

Tests and handover

Automated tests on the critical paths, technical documentation and a repository you own.

Barcode Scanner

Scanning inside the Shopware administration for order handling and stock, built for warehouse work that happens in the administration itself.

Postcode.eu

Address validation and autocomplete in the checkout, also in use at shops we did not build ourselves.

MailChimp Sync

Synchronisation between Shopware and your MailChimp lists, reviewed by Shopware just like our other extensions.

Plugin, app or theme: what the choice means for your update path

Shopware 6 has three kinds of extension, and that choice determines both how updatable you are and how free you are in hosting.

Plugin. PHP code running inside your own Shopware installation: custom entities, custom administration modules, hooks into the order flow. The price is that the plugin travels with your deployment process and has to be tested and adjusted on major releases. A plugin needs an environment of your own, which suits the way we prefer to run Shopware: hosted on-premise, so you keep control over performance, hosting and customisation.

App. Runs outside Shopware and communicates over the API and webhooks. Apps are loosely coupled, easier to update and the only route on a hosted environment. The trade-off is that you cannot reach as deep and depend on what the API exposes.

Theme. Touches the presentation layer only. The moment business logic ends up there, an architectural decision went wrong somewhere.

We choose per piece of functionality. A scanning flow inside the administration is a plugin, while an integration with an external platform that has its own dashboard is often an app. We make that call up front, not halfway through.

Ontwerp zonder titel (20)
shopware_logo_blue

Extension Partner means someone else reviews our code

Memo has been a Shopware Bronze Partner since 2018 and is also a Shopware Extension Partner. Being a Bronze Partner says something about the relationship with Shopware. Being an Extension Partner says something about the code. Our six extensions in the official Shopware Store have been reviewed by Shopware, are used in shops we did not build ourselves, and average five stars.

The team holds seven valid Shopware 6 certifications: three Certified Backend Developer, two Certified Frontend Developer, one Backend Developer Intermediate and one Frontend Developer Intermediate. Shopware lists app development, interface development and third-party integrations among our specialisations. More about the team is on the partner page.

The fastest way to judge how someone builds is to look at what is already out there. The full overview is on the plugin page:

We also build extensions that do not carry our logo, because they ship under the client's name. The official Shopware 6 plugin for PostNL is the best-known example.

The honest warning: stacked customisation

One plugin is manageable. Twelve are not. What we most often find in shops we take over is not a bad plugin, but a stack that grew over the years, where nobody remembers which ones are still in use, and which together make every upgrade expensive.

Custom work therefore carries not just build time but a structural maintenance line. Record for each extension why it exists and who uses it, and remove at every major release whatever nobody misses. What that does to your budget is covered on the page about Shopware costs.

If you build software for webshops yourself, your question is a different one: you are not extending one shop, you want your product available to every Shopware merchant. That calls for different decisions around versioning, Store publication and support for merchants who are your customers rather than ours. That is the subject of Shopware integration for technology partners.

Have a specific piece of functionality in mind and want to know whether it should be a plugin, an app or simply a setting? Bring the user story to a thirty-minute introduction. You will get a reasoned recommendation on the route and on the maintenance that follows.

Frequently asked questions

What does Shopware plugin development cost?

It depends on the complexity and on where the functionality intervenes. An extension that adds something to the administration is a different project from one that sits in the checkout or the order flow. We start with a short analysis and only then give a range, including the maintenance you should expect each year.

Will my plugin still work after a Shopware update?

On minor releases within the same line, almost always, provided the plugin uses the standard extension points. On a major version, adjustment is normal and planned work. For extensions we maintain we check for deprecations at every release, so an upgrade never comes as a surprise.

What is the difference between a plugin and an app in Shopware 6?

A plugin is PHP code running inside your own Shopware installation and can reach deep into the platform. An app runs outside it and talks over the API and webhooks. Apps are loosely coupled and work on hosted environments too, while plugins offer more but require an environment of your own.

Who owns the code you write?

You do. We deliver into a repository you own, with documentation, so another party could take it over. For extensions we publish in the Shopware Store we agree licensing and ownership in advance.

Can you take over custom work built by someone else?

Yes. We start with a technical review: how was it built, are core files overwritten, and what will it cost to bring it to the current Shopware line. Sometimes rebuilding is cheaper than repairing, and we will say so.