Shopware plugin development for your own software
You do not build webshops. You build software: a WMS, a payment solution, an ERP module, a carrier platform or a marketing tool. And you keep hearing the same question from prospects and resellers: “do you have a Shopware plugin?”
As long as the answer is no, you are the party in that conversation who creates extra work. A merchant on Shopware would rather pick the supplier already listed in the Store than the one whose agency has to build a connector first. It works the other way round too: an extension with your name on it sits permanently in a place where merchants search on their own.
.png)
Your own extension is a distribution channel, not an IT project
The biggest misconception we run into: a Shopware integration gets treated internally as a technical request from one customer. A connector is built for that single merchant, it lands in a private repository, and two years later not one additional merchant has been added.
An extension listed in the Shopware Store does something else. It is discoverable by merchants who have never heard of you, installable by agencies without you in the room, and it lowers the barrier in every sales conversation. That does mean treating it as a product: with a roadmap, a version number, a changelog and someone who answers the questions.
That shift is organisational more than technical. We help make the choice explicit up front: are you building a connector for one customer, or putting a product on the market? The answer drives the architecture.
Memo builds those extensions on behalf of software vendors, logistics providers and SaaS companies that want a presence in the Shopware market themselves. We have been a Shopware Bronze Partner since 2018 and are a Shopware Extension Partner with six of our own extensions in the official Store.
What publishing in the Store asks of you, and how we work together
The first four points are what an extension has to bring before Shopware approves it, and where the time goes. The last three are the models we work in with vendors in practice: pick the one that suits how much Shopware knowledge you want to build internally.
Code quality
No changes to the core, proper use of the official extension points, and code that follows Shopware standards.
Review process
Shopware tests every plugin manually before it appears in the Store. Count on iterations and on lead time.
Presentation in the Store
Descriptions, screenshots, supported languages and a clear pricing model are part of the product, not an afterthought.
Version management
With every new Shopware line you state which versions you support. Merchants can see in the Store whether you are behind.
Build and hand over
We develop the extension, publish it if you want, and transfer the repository, documentation and knowledge to your development team.
Build and maintain
We stay responsible for releases, compatibility with new Shopware versions and second-line support. You keep the customer relationship.
Extension of your team
You have developers but no Shopware specialists. We supply that knowledge inside your sprint rhythm and your architecture.
PostNL: an official Shopware 6 plugin in production
The brief. PostNL did not want one connector for one webshop, but a plugin that any Dutch or Belgian Shopware merchant can install. Memo developed that official Shopware 6 plugin in PHP. The code is public at github.com/postnl/shopware6.
What the plugin handles. Shipping labels and barcodes, domestic and international shipments inside and outside the EU, return labels that reuse the original outbound label, delivery options in the checkout, Dutch address validation, automated notification emails and multiple PostNL shipping products.
The UX decision. More interesting than the feature list is a decision we made together. Instead of long dropdowns full of shipping options, the plugin uses a dynamic system of toggles that matches shipping and delivery options to the merchant's preferences. That saves administrators configuration mistakes and reduces the number of support questions reaching PostNL.
After delivery. The work did not stop at go-live. The plugin is maintained continuously and compatibility with PostNL's new Landscape API is planned. The full story is in the PostNL case.
.png)
Code ownership and support for merchants
We do not build extensions you cannot walk away from. The code is yours, even when we maintain it, and it is delivered into a repository you own. With PostNL the code is even public on GitHub, which we think works well: it makes the quality verifiable for everyone who installs the plugin.
Once you are listed, questions arrive from shops you do not know, through agencies you do not know. That needs a channel and a response time. On support we therefore agree the boundaries in advance: which questions reach you and which reach us, who covers second line, and what happens on a critical Shopware release.
As a Shopware partner we are bound to respond within four working days. That is the floor; what your merchants need is usually above it, and we settle that in the partnership agreement rather than leaving it to good intentions.
Our seven Shopware 6 certifications and the five-star average on our own extensions say something about quality, but the division of responsibility we simply put in writing.
Why a Shopware partner rather than your own team
Your developers can certainly write PHP. What they usually lack is experience with the conventions of Shopware 6, with what a Store review rejects, and with what changes at each release. You will not see that difference in version 1.0. You will see it at the third Shopware update.
How we build and test, and when a plugin is the wrong solution, is covered on the page about Shopware plugin and extension development. Who the team is and which certifications are in house is on the partner page. An overview of everything we do around Shopware sits on the Shopware hub.
How long the whole thing takes depends heavily on the complexity of your product and on what you want it to do. One thing is predictable: Shopware tests every plugin manually before it appears in the Store. That is human work rather than an automated scan, so there is lead time between submission and publication. Plan your release calendar and your marketing around that, not the other way round.
Want to know what it takes to bring your software to market as a Shopware extension? Bring your API documentation and the merchant question you hear most to a thirty-minute conversation, and we will map the route together: your own extension or a custom connector, in the Store or white label, and who handles which support.
Frequently asked questions
We already have a REST API. Why would we need a Shopware extension?
Because an API only creates value once someone connects it. With an extension in the Store, a merchant or agency installs your integration in minutes, without a custom project and without your help. That shortens your sales cycle and takes implementation work off your plate.
Who owns the code you write for us?
You do. We work in a repository you own and deliver documentation another team could pick up. Publishing under your name, white label, or public on GitHub are all possible. We agree that in advance.
Who answers merchant questions after launch?
That is agreed up front. In the build-and-maintain model we take the technical second line and you keep the customer relationship. On a handover, your own support team covers everything, with documentation and a technical transfer from us.
What happens when Shopware releases a new major version?
We test the extension against it, resolve deprecations and ship a compatible release. For extensions we maintain, that is planned work. Merchants can see in the Store which Shopware versions you support, so falling behind visibly costs you installations.
Can you turn an existing connector into a Store extension?
Yes, and it is a common starting point. We first assess what is customer-specific and what is generic, and which assumptions from that one project have to go before the extension works for every merchant.