Shopware plugin ontwikkelen voor je eigen software
Je bouwt geen webshops. Je bouwt software: een WMS, een betaaloplossing, een ERP-module, een vervoerdersplatform of een marketingtool. En steeds vaker krijg je dezelfde vraag van prospects en resellers: “hebben jullie een Shopware-plugin?”
Zolang het antwoord nee is, ben je in dat gesprek de partij die extra werk kost. Een merchant die op Shopware zit, kiest liever de leverancier die al in de Store staat dan de leverancier waarvoor zijn bureau eerst een koppeling moet bouwen. Andersom werkt het net zo goed: een extensie met jouw naam erop staat permanent op een plek waar merchants zelf zoeken.
Een eigen extensie is een distributiekanaal, geen IT-project
De grootste denkfout die we tegenkomen: een Shopware-integratie wordt intern behandeld als een technisch verzoek van één klant. Er wordt een koppeling gebouwd voor die ene merchant, die belandt in een privérepository, en twee jaar later is er geen enkele merchant bijgekomen.
Een extensie die in de Shopware Store staat, doet iets anders. Die is vindbaar voor merchants die jou nog niet kennen, is installeerbaar door bureaus zonder dat jij aan tafel zit, en verlaagt de drempel in elk verkoopgesprek. Dat betekent wel dat je hem als product moet behandelen: met een roadmap, een versienummer, een changelog en iemand die de vragen beantwoordt.
Die verschuiving is vooral een organisatorische, niet een technische. Wij helpen om die keuze vooraf scherp te krijgen: bouw je een koppeling voor één klant, of zet je een product in de markt? Het antwoord bepaalt de architectuur.
Memo bouwt die extensies in opdracht van softwareleveranciers, logistiek dienstverleners en SaaS-partijen die zelf in de Shopware-markt willen staan. We zijn Shopware Bronze Partner sinds 2018 en Shopware Extension Partner met zes eigen extensies in de officiële Store.
Wat publicatie in de Store vraagt, en hoe we samenwerken
De eerste vier punten zijn wat een extensie moet meebrengen voordat Shopware hem goedkeurt, en waar de tijd in gaat zitten. De laatste drie zijn de vormen waarin we in de praktijk met leveranciers werken: kies de vorm die past bij hoeveel Shopware-kennis je intern wilt opbouwen.
Codekwaliteit
Geen aanpassingen aan de kern, netjes gebruik van de officiële extension points en code die de Shopware-standaarden volgt.
Reviewproces
Shopware test elke plugin handmatig voordat hij in de Store verschijnt. Reken op iteraties en op doorlooptijd.
Presentatie in de Store
Beschrijvingen, screenshots, ondersteunde talen en een duidelijk prijsmodel horen bij het product, niet bij de afwerking achteraf.
Versiebeheer
Bij elke nieuwe Shopware-lijn geef je aan welke versies je ondersteunt. Merchants zien in de Store of je achterloopt.
Bouwen en overdragen
Wij ontwikkelen de extensie, publiceren hem indien gewenst en dragen repository, documentatie en kennis over aan jouw ontwikkelteam.
Bouwen en onderhouden
Wij blijven verantwoordelijk voor releases, compatibiliteit met nieuwe Shopware-versies en tweedelijns support. Jij houdt het klantcontact.
Verlengstuk van je team
Je hebt zelf ontwikkelaars maar geen Shopware-specialisten. Wij leveren die kennis binnen jouw sprintritme en jullie architectuur.
PostNL: een officiële Shopware 6-plugin in productie
De opdracht. PostNL wilde niet één koppeling voor één webshop, maar een plugin die elke Nederlandse en Belgische Shopware-merchant kan installeren. Memo ontwikkelde die officiële Shopware 6-plugin in PHP. De code staat publiek op github.com/postnl/shopware6.
Wat de plugin regelt. Verzendlabels en barcodes, binnenlandse en internationale zendingen binnen en buiten de EU, retourlabels waarbij het heenlabel opnieuw wordt gebruikt, bezorgopties in de checkout, Nederlandse adresvalidatie, geautomatiseerde notificatiemails en meerdere PostNL-verzendproducten.
De UX-keuze. Interessanter dan de featurelijst is een beslissing die we samen maakten. In plaats van lange dropdowns met verzendopties werkt de plugin met een dynamisch systeem van toggles dat verzend- en bezorgopties matcht op de voorkeuren van de merchant. Dat scheelt beheerders configuratiefouten en verlaagt het aantal supportvragen dat bij PostNL binnenkomt.
Na oplevering. Het werk stopte niet bij de livegang. De plugin wordt doorlopend onderhouden en de compatibiliteit met de nieuwe Landscape API van PostNL staat gepland. Het volledige verhaal lees je in de PostNL-case.
Eigenaarschap van de code en support aan merchants
Wij bouwen geen extensies waar je niet meer vanaf komt. De code is van jou, ook als wij hem beheren, en wordt opgeleverd in een repository waar jij eigenaar van bent. Bij PostNL staat de code zelfs publiek op GitHub, wat wat ons betreft prima werkt: het maakt de kwaliteit controleerbaar voor iedereen die de plugin installeert.
Zodra je in de Store staat, komen er vragen binnen van shops die jij niet kent, via bureaus die jij niet kent. Daar hoort een kanaal en een reactietermijn bij. Over support maken we daarom vooraf harde afspraken: welke vragen bij jou binnenkomen en welke bij ons, wie tweedelijns is, en wat er gebeurt bij een kritieke Shopware-release.
Als Shopware-partner zijn we gebonden aan een reactie binnen vier werkdagen. Dat is de ondergrens; wat jouw merchants nodig hebben ligt daar meestal boven, en dat regelen we in de samenwerkingsafspraak in plaats van het aan goede bedoelingen over te laten.
Onze zeven Shopware 6-certificeringen en de gemiddelde beoordeling van vijf sterren op onze eigen extensies zeggen iets over de kwaliteit, maar de afspraken over verantwoordelijkheid zetten we gewoon op papier.
Waarom een Shopware-partner en niet je eigen team
Je developers kunnen ongetwijfeld PHP. Wat ze meestal niet hebben is de ervaring met de conventies van Shopware 6, met wat een Store-review afkeurt, en met wat er per release verandert. Dat verschil zie je niet in versie 1.0, maar wel bij de derde Shopware-update.
Hoe wij technisch bouwen en testen, en wanneer een plugin de verkeerde oplossing is, staat op de pagina over Shopware plugin- en extensionontwikkeling. Een overzicht van alles wat we rond Shopware doen staat op de Shopware-hub.
Hoeveel tijd het geheel kost, hangt sterk af van de complexiteit van je product en van je wensen. Eén ding is wel voorspelbaar: Shopware test elke plugin handmatig voordat hij in de Store verschijnt. Dat is geen geautomatiseerde scan maar mensenwerk, dus tussen inzending en publicatie zit doorlooptijd. Plan je releasekalender en je marketing daaromheen, niet andersom.
Wil je weten wat er nodig is om jouw software als Shopware-extensie in de markt te zetten? Neem je API-documentatie en je belangrijkste merchantvraag mee naar een gesprek van dertig minuten, dan schetsen we samen de route: eigen extensie of maatwerkkoppeling, in de Store of white label, en wie welke support doet.
Veelgestelde vragen
Wij hebben al een REST API. Waarom dan nog een Shopware-extensie?
Omdat een API pas waarde krijgt als iemand hem koppelt. Met een extensie in de Store installeert een merchant of bureau jouw integratie in minuten, zonder maatwerkproject en zonder jouw hulp. Dat verkort je verkoopcyclus en haalt implementatiewerk bij je vandaan.
Van wie is de code die jullie voor ons schrijven?
Van jou. We werken in een repository waar jij eigenaar van bent en leveren documentatie mee waarmee een ander team het kan overnemen. Publiceren onder jouw naam, white label of publiek op GitHub is allemaal mogelijk. We leggen dat vooraf vast.
Wie beantwoordt de vragen van merchants na livegang?
Dat spreken we af. Bij het model bouwen en onderhouden nemen wij de technische tweede lijn en houd jij het klantcontact. Bij overdracht doet jouw eigen supportteam alles, met documentatie en een technische overdracht van ons.
Wat gebeurt er als Shopware een nieuwe majorversie uitbrengt?
Dan testen we de extensie tegen die versie, lossen we deprecations op en brengen we een compatibele release uit. Voor extensies die wij beheren is dat gepland werk. Merchants zien in de Store welke Shopware-versies je ondersteunt, dus achterlopen kost je zichtbaar installaties.
Kunnen jullie een bestaande koppeling ombouwen tot een Store-extensie?
Ja, en dat is een veelvoorkomend startpunt. We beoordelen eerst wat klantspecifiek is en wat generiek, en welke aannames uit dat ene project eruit moeten voordat de extensie voor elke merchant werkt.