Die Frage stellt sich fast in jedem Shopware-Projekt. Dein Standard-Shop reicht nicht aus. Du brauchst spezielle Logik, individuelle Checkout-Prozesse oder eine Anbindung zu deinem ERP-System. Aber wie setzt du das um? Apps aus dem Shopware Store, selbst entwickelte Plugins oder direkter Custom Code im System?
Wir setzen seit 2012 Shopware-Projekte um und dabei gelernt, dass es keine universelle Antwort gibt. Aber es gibt klare Kriterien, nach denen du die richtige Entscheidung triffst.
Inhalt
- Shopware Apps: Der Standard-Weg
- Eigene Plugins schreiben oder verwenden?
- Wann ist Custom Code notwendig?
- Die Kosten-Realität
- Wartung und Update-Sicherheit
- Unsere Empfehlung für dein Projekt
Shopware Apps: Der Standard-Weg
Apps sind die moderne Antwort von Shopware auf die Frage "Wie erweitere ich meinen Shop?". Sie sind keine Plugins mehr, sondern eigenständige Anwendungen, die über APIs mit deinem Shop kommunizieren. Das klingt komplizierter als es ist.
Der Vorteil: Apps sind isoliert. Sie beeinflussen den Core von Shopware nicht. Du kannst sie problemlos installieren, testen und wieder entfernen. Das macht das Risiko deutlich kleiner. Der Shopware Store hat mittlerweile über 3.000 Apps, viele davon kostenlos oder im kostengünstigen Abo.
Der Nachteil: Nicht jede App tut genau das, was du brauchst. Und wenn sie fast passt, aber nicht ganz, dann musst du entweder damit leben oder eine andere Lösung suchen. Apps sind auch nicht ideal für tiefe Systemintegration. Wenn du dein Lagersystem live mit Shopware synchronisieren musst, wird eine Standard-App schnell zur Krücke.
In unseren Projekten nutzen wir gerne vorgefertigte Apps als Basis. 70% der Standard-Anforderungen lassen sich damit abdecken.
Eigene Plugins schreiben oder verwenden?
Plugins sind die klassische Shopware-Erweiterung. Sie greifen tiefer ins System ein als Apps, laufen im gleichen Prozess wie der Shop selbst. Das macht sie mächtig, aber auch anfälliger für Konflikte.
Shopware 6 hat das Plugin-System deutlich verbessert. Gute Plugins sind testbar, wartbar und folgen klaren Strukturen. Es gibt viele hochwertige Third-Party-Plugins, die Dinge wie Zahlungsabwicklung, Versandlogik oder Marketing-Automation lösen.
Das Problem: Plugin-Qualität variiert massiv. Ein schlechtes Plugin kann deinen Shop verlangsamen oder sogar bei Updates kaputt gehen. Und wenn ein Plugin genau das macht, was du brauchst, aber nur zu 80%, dann zahlst du für etwas, das du nicht brauchst.
Custom Plugins schreiben lassen ist teuer. 20.000+ EUR je nach Komplexität. Aber: Ein gut geschriebenes Plugin ist wiederverwendbar, testbar und professionell wartbar.
Bei dasistweb schreiben wir Plugins nur dann, wenn sie ein Standard-Problem lösen, das mehrere Kunden haben. Sonst ist direkter Custom Code günstiger und besser wartbar.
Wann ist Custom Code notwendig?
Custom Code bedeutet: Du änderst und erweiterst Shopware direkt im Code, ohne Plugin oder App. Das ist riskant, aber manchmal die einzige Lösung.
Aber hier kommt Martins Faustregel: Heavy Customizing hat außerhalb von Shopware stattzufinden.
Warum? Wenn du deine Software IN Shopware baust, musst du ALLE Update-Entscheidungen aller Frameworks darunter mittragen: Symfony, Vue, UND Shopware. Das ist architektonisch ein grober Fehler. Shopware ist ein Zauberponyland: Kann fast alles, aber man darf nicht alles kombinieren. Heavy Custom wird dich bei Wartung einholen.
Das heißt konkret:
- Frontend Heavy Custom → Headless Commerce (dein Frontend, Shopware als reine API)
- Backend Heavy Custom → Microservices daneben (z.B. Symfony Service, separate vom Shop)
- Kleine Anpassungen in Shopware: OK. Ab 30% Custom: Die Architektur muss sich ändern (Headless Frontend oder Microservices). Nicht die Plattform wechseln, sondern anders strukturieren.
Typische Szenarien für kleine Anpassungen:
- Checkout-Logik die Shopware Flows abdeckt
- Preislogik über Custom Prices oder Promotion Rules
- Standard B2B-Integration über APIs
- Einfache Content-Erweiterungen über Custom Fields
Custom Code ist schneller zu bauen und günstiger als ein Plugin zu schreiben. Aber die Wartung wird zum Problem. Jedes Shopware-Update ist eine potenzielle Quelle für Konflikte. Wenn Shopware eine interne Funktion ändert, die du überschrieben hast, dann bricht dein Code.
In unseren Projekten vermeiden wir Pure Custom Code, wo es geht. Bei Stufe 3 und 4 Projekten (Headless, individuelle Integration) bauen wir architektonisch richtig: Mit klarer Trennung von Shopware und Custom-Logik.
Die Kosten-Realität
Hier wird es konkret. Die Preise unterscheiden sich deutlich:
Shopware App installieren: Kostenlos bis mehrere Hundert EUR/Monat, je nachdem ob kostenlos oder im Abo.
Third-Party Plugin: Kostenlos bis mehrere Tausend EUR einmalig, dann meist laufende Kosten für Updates und Support.
Custom Plugin schreiben: 15.000+ EUR je nach Komplexität, plus laufende Wartungskosten.
Custom Code (eine spezifische Funktion): Ab einigen Tausend EUR je nach Aufwand. Wartung wird kritisch.
Die häufigste Falle: Du fragst eine Agentur "Wie viel kostet es, feature X zu bauen?" und bekommst eine Antwort. Dann vier Monate später das erste Update, dein Feature bricht, und plötzlich kostet der Fix 5.000 EUR. Was Shopware Wartung langfristig kostet und wie man das plant, erklären wir in einem eigenen Artikel.
Bei dasistweb kalkulieren wir Wartung immer mit ein. Wenn wir dir Custom Code schreiben, dann zeigen wir dir, welche Tests dahinterstehen und wie man es sicher updatet.
Wartung und Update-Sicherheit
Das ist der Knackpunkt, den viele Agenturen ignorieren. Shopware bringt regelmäßig Updates. Kleine Patches monthly, größere Versionen 2-3x im Jahr.
Mit Apps: Zero Problem. Apps bekommst du automatisch upgedatet von den Entwicklern.
Mit Plugins: Die Plugin-Entwickler müssen testen. Gute Plugins werden schnell upgedatet, schlechte Plugins manchmal Monate später oder überhaupt nicht.
Mit Custom Code: Du selbst musst testen und updaten. Das bedeutet Zeit und Geld bei jedem Shopware-Update.
Das ist der Grund, warum viele Shops auf veralteten Shopware-Versionen laufen. Die Custom-Logik passt zu einer bestimmten Version, und jedes Update ist ein Risiko.
Unsere Faustregel: Wähle immer die Lösung mit der geringsten Wartungslast. Eine App, die 90% deiner Anforderung erfüllt, ist oft besser als Custom Code für 100%.
Unsere Empfehlung für dein Projekt
So gehen wir vor:
- Was brauchst du wirklich? Manchmal denkt man, dass man Custom braucht, aber ein paar Konfigurationen reichen aus.
- Gibt es eine App dafür? Shopware Store durchsuchen, vergleichen. Wenn ja, Test-Installation machen.
- Gibt es ein gutes Plugin? Referenzen checken, Bewertungen lesen, Support testen.
- Brauchst du wirklich Custom? Wenn die obigen Optionen nicht ausreichen. Dann klären wir: Plugin schreiben (wenn es wiederverwendbar ist) oder direkte Anpassung (wenn es einmalig ist).
Bei Stufe 1 und 2 Projekten (Theme + Konfiguration, Standard-Anbindungen) nutzen wir meist 80% Apps und Plugins, 20% Custom.
Bei Stufe 3 und 4 (Individuelles Frontend, Headless) ist der Custom-Anteil höher, aber wir bauen immer mit Test-Coverage und sauberer Architektur.
Fazit: Technologie ist Werkzeug, nicht Ziel
Beim Shopware Customizing gilt: Apps, Plugins und Custom Code sind Werkzeuge. Der Fehler ist, sich in eines davon zu verlieben. Die beste Lösung ist die, die:
- Deine Anforderung erfüllt
- Mit Updates mitkommt
- Nicht mehr kostet als nötig
- Jemand wartbar übernehmen kann
Die meisten Agenturen bauen Custom, weil sie dann über Jahre Geld verdienen. Wir bauen Custom, nur wenn es wirklich sinnvoll ist. Das ist ehrlicher und günstiger für dich.