DE
EN
Du skalierst gerade deinen Shop und merkst, dass sich manche Dinge anfühlen wie ein zu enges Kleid nach Pizza und Eis. Es geht noch, aber du bewegst dich nicht mehr frei. Bestellungen steigen, Teams wachsen, Kanäle werden mehr und plötzlich kostet jedes kleine Feature Wochen. Das ist oft der Moment, wo die Frage aufpoppt: Reicht ein Standard-Shop mit Plugins noch, oder brauchst du Custom-Development?
Ich nehme dich hier mit durch klare Kriterien, echte Praxisfragen und eine Entscheidung, die du später nicht bereuen willst. Kein Tech-Gelaber zum Angeben, sondern Orientierung, die du direkt im Alltag nutzen kannst. Und ja, manchmal ist Custom-Code nur teurer Bastelspaß. Manchmal ist er dein Rettungsring.
Wenn du neben Skalierung auch rechtliche Basics und Shop-Pflichten sauber halten willst, schau bei dieser Quelle rein:Händlerbund Ratgeber zu Shop-Pflichten und E-Commerce-Recht
.
Das hilft dir, damit Wachstum nicht an Kleinigkeiten scheitert.
Was ist mit Standard-Shop gemeint und was ist Custom-Development?
Standard-Shop
Ein Standard-Shop ist ein Shopsystem, das du mit Themes, Apps, Plugins und Konfiguration betreibst. Du nutzt die vorgesehenen Funktionen und ergänzt, was fehlt, über Erweiterungen. Das ist oft schnell, planbar und für viele Use Cases absolut passend.
Custom-Development
Custom-Development ist Code, der speziell für dein Business gebaut wird. Das kann klein starten, zum Beispiel ein eigener Checkout-Schritt. Es kann auch groß werden, zum Beispiel ein eigenes PIM-Modul, eine eigene Preislogik oder ein kompletter Middleware-Layer zwischen Shop, ERP, CRM und Logistik.
Die Kernfrage: Was bremst dich wirklich?
Viele entscheiden aus Bauchgefühl. Bitte nicht. Stell dir lieber diese Frage: Was kostet dich das aktuelle Setup jeden Monat an Zeit, Umsatz oder Nerven? Wenn du das sauber benennen kannst, wird die Entscheidung klarer.
Typische Bremsen beim Skalieren sehen so aus:
- Checkout wird langsam oder bricht bei Lastspitzen ein.
- Preisregeln werden so komplex, dass du sie nicht mehr testen kannst.
- Daten sind doppelt, falsch oder zu spät, weil Systeme nicht sauber sprechen.
- Marketing will Kampagnen, aber dein System kann keine schnellen Änderungen.
- B2B-Logik sprengt das, was Plugins sauber abbilden.
- Teams warten aufeinander, weil jede Änderung ein Risiko ist.
Wenn du jetzt innerlich bei drei Punkten genickt hast, dann lies weiter. Wenn du bei null bist, dann spar dir Custom-Code und investier erst in saubere Konfiguration, Content und Tracking. Ja, ich habe es gesagt.
Wann Standard-Shops beim Skalieren weiter tragen als du denkst
Ein Standard-Shop kann auch bei hohem Umsatz funktionieren, wenn du diese Dinge im Griff hast:
- Du nutzt ein solides Hosting-Setup mit Caching und sauberen Deployments.
- Du hältst Plugin-Anzahl klein und prüfst Qualität und Update-Strategie.
- Du trennst Frontend-Optimierung von Business-Logik, wo es möglich ist.
- Du definierst Prozesse, wer wann was ändert und wie getestet wird.
Der Punkt ist: Viele Shops skalieren nicht wegen fehlender Features schlecht, sondern wegen Chaos. Zu viele Plugins, zu viele Sonderwege, keine Tests, kein Staging, kein Monitoring. Das fühlt sich dann nach Feature-Problem an, ist aber ein Prozess-Problem.
Die klaren Signale, dass Custom-Development sinnvoll wird
1) Deine Business-Logik ist dein Wettbewerb
Wenn dein Umsatz daran hängt, dass du Dinge anders machst als andere, dann brauchst du Kontrolle. Beispiele: dynamische Preislogik je Kundengruppe und Verfügbarkeit, Angebotsprozesse für B2B, komplexe Bundles, Konfiguratoren, spezielle Abo-Modelle, oder eine Lieferlogik, die mehr kann als Standard.
2) Integrationen kosten dich dauerhaft Zeit
Wenn du jeden Tag in Excel Babysitting machst, weil ERP, Shop und Versand nicht sauber synchron sind, dann zahlst du eine versteckte Steuer. Custom-Development lohnt sich, wenn du wiederkehrende manuelle Arbeit eliminierst. Das ist messbar.
3) Performance ist Umsatz, nicht Kosmetik
Wenn dein Shop bei Kampagnen langsamer wird, steigen Abbrüche. Dann ist Performance kein Nice-to-have. Oft reicht Tuning. Manchmal brauchst du aber Architektur: entkoppelte Services, klare Datenflüsse, eigene APIs, saubere Caches.
4) Du hast Compliance und Sicherheit als echte Anforderungen
Wenn du mit sensiblen Daten arbeitest, viele Rollen und Rechte brauchst oder Audits hast, wird es ernst. Dann willst du kontrollierbare Prozesse, Logging, Rollenmodelle und klare Rechteverwaltung. Das ist mit Plugin-Patchwork oft schwierig.
Zum Thema Sicherheit und saubere Schutzmaßnahmen ist diese Quelle gut, weil sie konkrete Orientierung gibt:BSI Empfehlungen für Unternehmen zur IT-Sicherheit
.
Skalierung shop ecommerce – Allgemein – ⚙️Skalierung im E-Commerce: Wann lohnt sich ein Custom-Development statt Standard-Shop?🚀
Die Entscheidungslogik, die ich in Projekten nutze
Ich nutze eine simple Matrix aus vier Achsen. Du kannst sie auf ein Blatt Papier schreiben und dein Team damit durch den Raum schicken.
Achse A: Häufigkeit
Wie oft tritt das Problem auf? Täglich, wöchentlich, saisonal, selten?
Achse B: Impact
Wie groß ist der Schaden oder der Gewinn? Geld, Zeit, Risiko, Conversion, Supportlast.
Achse C: Komplexität
Ist das Problem klar abgrenzbar oder zieht es fünf Systeme rein?
Achse D: Differenzierung
Ist das Feature Standard im Markt, oder ist es deine besondere Logik?
Regel, die fast immer stimmt:
- Hoch bei Häufigkeit und hoch bei Impact, das ist ein Kandidat für Custom.
- Hoch bei Differenzierung und mittel bis hoch bei Impact, das ist oft Custom.
- Niedrig bei Differenzierung, dann erst prüfen, ob Standard-Optionen reichen.
Die Kostenfrage, die viele falsch rechnen
Viele rechnen nur Entwicklungskosten. Das ist wie Urlaub nur mit Flug vergleichen. Du brauchst den ganzen Blick:
- Build: Entwicklung, Testing, Doku, Release.
- Run: Hosting, Monitoring, Wartung, Sicherheitsupdates.
- Change: Weiterentwicklung, Bugfixing, neue Anforderungen.
- People: Wissen im Team, Übergabe, Onboarding.
- Risk: Ausfallkosten, Datenfehler, Rechtsrisiken.
Eine praktische Daumenregel für deine Planung: Wenn du Custom baust, plane auch Budget für Pflege ein. Sonst hast du nach einem Jahr einen Schatz, den niemand mehr anfassen will. Das fühlt sich dann an wie ein Haustier, das du vergessen hast zu füttern. Nicht gut.
Welche Custom-Optionen es gibt, ohne gleich alles neu zu bauen
Custom ist kein Entweder-oder. Du hast Abstufungen. Und die sind Gold wert, wenn du kontrolliert skalieren willst.
Option 1: Custom innerhalb des Shopsystems
Du baust ein eigenes Plugin oder Modul. Vorteil: Schnell integrierbar, nutzt Shop-Standards, gute Wartbarkeit bei sauberem Code. Risiko: Du bleibst an Systemgrenzen gebunden.
Option 2: Middleware für Integrationen
Du entkoppelst ERP, PIM, CRM, Versand und Shop über einen Integrationslayer. Vorteil: Stabilere Datenflüsse, klare Schnittstellen, weniger direkte Abhängigkeiten. Das ist oft der größte Skalierungshebel, weil Teams endlich weniger manuell arbeiten.
Option 3: Headless oder Composable Bausteine
Du trennst Frontend und Backend oder nutzt einzelne Services. Vorteil: Flexible Frontends, Performance-Optionen, bessere Team-Aufteilung. Risiko: Mehr Architekturarbeit, mehr Verantwortung bei Betrieb und Monitoring.
Option 4: Eigener Kern, Shop nur als Kanal
Das ist die große Liga. Du baust zentrale Logik selbst und nutzt Shopsysteme als Ausspielkanal. Das lohnt sich nur, wenn du wirklich viele Kanäle, Länder, Preislogiken oder besondere Prozesse hast.
Custom-Development lohnt sich besonders in diesen Szenarien
B2B mit echter Komplexität
Wenn du Angebote, Budgets, Freigaben, Staffelpreise, kundenspezifische Sortimente, Rahmenverträge oder Rollenmodelle brauchst, kommst du mit Standard oft schnell an Grenzen. Plugins können helfen, aber sie bilden selten genau deine Prozesse ab. Custom kann hier Ordnung schaffen, wenn du vorher Prozesse sauber definierst.
Viele Produkte, viele Daten, viele Regeln
Wenn du große Kataloge hast, wird Datenqualität zum Umsatzfaktor. Dann brauchst du saubere Importlogik, Validierung, Versionierung, automatische Checks, und klare Zuständigkeiten. Custom-Tools und Middleware zahlen sich aus, weil Fehler sonst jeden Tag Zeit fressen.
Internationalisierung mit Steuer, Währung, Logistik
Mehr Länder bedeuten mehr Sonderfälle. Lieferzonen, Steuersätze, Versandlogik, Zahlungsmethoden, lokale Anforderungen. Standard kann vieles, aber du brauchst oft Ergänzungen, die sauber getestet werden. Hier ist Custom oft sinnvoll, wenn du mehr als ein Land ernsthaft betreibst.
Der Klassiker: Plugin-Wildwuchs und warum er bei Wachstum teuer wird
Plugins sind toll, bis sie sich gegenseitig in die Haare kriegen. Typische Probleme:
- Update-Kettenreaktion, weil ein Plugin ein anderes blockiert.
- Performance-Einbruch, weil mehrere Plugins am gleichen Hook hängen.
- Kein klarer Owner für Bugs, weil jeder auf jeden zeigt.
- Checkout ist ein Puzzle aus fünf Erweiterungen.
Wenn du skalierst, willst du weniger bewegliche Teile, nicht mehr. Das heißt nicht, dass du keine Plugins nutzt. Es heißt: Du kuratierst sie. Und du baust kritische Logik lieber selbst, wenn sie Kernprozesse berührt.
So gehst du praktisch vor, ohne dich zu verrennen
Schritt 1: Mappe deine Kernprozesse
Schreib die Journey von Bestellung bis Versand auf. Wirklich Schritt für Schritt. Wo entstehen manuelle Handgriffe? Wo entstehen Fehler? Wo warten Teams? Das ist dein Budget-Leak.
Schritt 2: Definiere Ziele als messbare Werte
Beispiele:
- Bestandsabweichung von X auf Y reduzieren.
- Time-to-Ship um Z Stunden senken.
- Checkout-Abbruchrate um N Prozentpunkte senken.
- Support-Tickets zu Zahlungsproblemen halbieren.
Schritt 3: Entscheide zuerst über Architektur, dann über Code
Wenn du sofort Feature-Listen schreibst, baust du schnell am Symptom. Prüfe zuerst: Was muss zentral sein? Was kann im Shop bleiben? Was gehört in eine Middleware? Das spart dir später Umbauten.
Schritt 4: Baue klein, releasbar, testbar
Custom muss in kleine Inkremente. Jede Einheit braucht Tests, Doku und Monitoring. Und ja, das klingt nach Disziplin. Es spart dir aber Ausfälle und Drama im Peak.
Welche Fragen du deinem Team oder deiner Agentur stellen solltest
Wenn jemand dir Custom-Development anbietet, stell diese Fragen. Und hör auf die Antworten, nicht auf die Folien.
- Wie wird getestet, automatisiert und manuell?
- Wie sieht das Deployment aus, inkl. Rollback?
- Wie werden Logs, Monitoring und Alerts umgesetzt?
- Wie wird dokumentiert, damit dein Team es versteht?
- Wie werden Updates des Shopsystems berücksichtigt?
- Was passiert, wenn die Person, die es gebaut hat, weg ist?
Mini-Checkliste: Lohnt sich Custom bei dir gerade?
Mach es pragmatisch. Wenn du viermal Ja sagst, bist du im Custom-Bereich. Wenn du ein bis zwei Ja sagst, bleib erstmal beim Standard und optimiere Setup und Prozesse.
- Wir haben monatlich wiederkehrende manuelle Arbeit, die wir klar benennen können.
- Unsere Kernlogik passt nicht sauber in Plugins, ohne Workarounds.
- Wir verlieren Umsatz durch Performance, Checkout oder Datenfehler.
- Wir haben Integrationen, die regelmäßig ausfallen oder nachlaufen.
- Unsere Plugin-Landschaft ist schwer zu warten und zu updaten.
- Wir brauchen Rollen, Rechte, Audits oder sauberes Logging.
Wenn du Custom baust, diese Fehler solltest du vermeiden
Fehler 1: Custom ohne Produktverantwortung
Wenn niemand Owner ist, veraltet alles. Definiere eine Person oder Rolle, die Entscheidungen trifft, Prioritäten setzt und Pflege budgetiert.
Fehler 2: Kein Staging, keine Tests
Ohne Testumgebung und klare Release-Prozesse baust du Stress in jede Änderung. Das wird bei Wachstum nur schlimmer.
Fehler 3: Zu viel auf einmal
Wenn du alles neu baust, verlierst du Fokus. Baue die Engpässe zuerst. Bring sie live. Miss den Effekt. Dann weiter.
Fehler 4: Datenmodell vergessen
Skalierung ist oft ein Datenproblem. Artikel, Preise, Kunden, Bestände, Aufträge. Wenn das Modell wackelt, wackelt alles. Plane Datenflüsse und Verantwortlichkeiten bewusst.
Ein kurzer Reality-Check zu Recht und Pflichten
Beim Skalieren kommen neue Risiken dazu, zum Beispiel mehr Zahlungsarten, mehr Länder, mehr Tracking, mehr Teamzugriffe. Das betrifft auch Rechtsthemen. Wenn du an Checkout, Tracking oder Kundenkonto schraubst, prüfe Pflichten und Dokumentation.
Eine zuverlässige Quelle für Gesetzestexte ist:Gesetze im Internet vom Bundesministerium der Justiz
.
Nutz das, wenn du bei Pflichtangaben, Widerruf, Datenschutz oder Vertragskram sauber bleiben willst.
Jetzt bist du dran: Erzähl mir deinen Fall
Ich will es konkret wissen, weil daraus oft die besten Lösungen entstehen. Was bremst dich gerade beim Skalieren?
- Ist es Performance?
- Ist es ERP und Bestände?
- Ist es B2B-Logik?
- Ist es Plugin-Chaos?
🚀 FAQ, Skalierung im E-Commerce, Standard Shop oder Custom Development
10 Fragen, die dir helfen, schneller zu entscheiden. Klar, praxisnah, mit Fokus auf Umsatz, Aufwand und Risiko.
Woran merke ich, dass mein Standard Shop beim Wachstum an Grenzen kommt?
Du merkst es selten an einem großen Knall. Es sind kleine Dinge, die sich häufen. Updates machen Angst, weil irgendwas danach spinnt. Kampagnen bringen Traffic, aber der Checkout wird zäh. Dein Team macht Workarounds in Excel, weil Systeme nicht sauber zusammenspielen.
Wann lohnt sich Custom Development finanziell wirklich?
Wenn du damit dauerhaft Kosten senkst oder Umsatz schützt. Custom lohnt sich oft, wenn du repetitive Arbeit eliminierst, Abbrüche reduzierst oder Fehlerquellen aus Datenflüssen entfernst. Rechne nicht nur Entwicklung, rechne auch Pflege und Betrieb.
Automatische Preislogik, stabile ERP Synchronisierung, Checkout Optimierung bei Last, B2B Rollen und Freigaben
Optische Sonderwünsche ohne Conversion Effekt, Sonderfeatures die du nur alle paar Monate nutzt
Welche Funktionen sollte ich eher custom bauen statt Plugins zu stapeln?
Alles, was deinen Checkout, Preise, Bestände, Versandlogik oder Kundendaten direkt beeinflusst, ist kritisch. Wenn dafür drei Plugins gleichzeitig am gleichen Prozess schrauben, wird es schnell fragil. Bei Wachstum willst du weniger bewegliche Teile.
Was ist der größte Fehler bei Custom Development in Shops?
Custom ohne Verantwortung, ohne Tests, ohne sauberen Release Prozess. Dann hast du ein Feature, das keiner anfassen will. Und wenn jemand es doch anfasst, brennt es. Nicht aus Bosheit, sondern weil Wissen fehlt.
Warum eskaliert das Thema bei B2B Shops so schnell?
B2B ist selten nur ein anderer Preis. Du hast Rollen, Budgets, Freigaben, Angebote, Rahmenverträge, kundenspezifische Sortimente. Das sind Prozesse, keine Features. Standard kann viel, aber deine Abläufe sind meist spezieller als dein Theme.
Einfache Kundengruppen Preise, Rechnungszahlung, Firmenkunden Registrierung
Mehrstufige Freigaben, Angebotserstellung, individuelle Preislisten, Rechte je Abteilung
Muss ich für Custom gleich Headless oder Composable machen?
Nein. Custom kann klein starten. Ein eigenes Modul im Shopsystem, eine saubere API, eine Middleware für ERP. Headless lohnt sich eher, wenn du viele Touchpoints hast oder dein Frontend extrem flexibel sein muss.
Welche Rolle spielen ERP, PIM und CRM bei der Entscheidung?
Eine riesige. Viele Shops bremsen, weil Daten zu spät oder falsch ankommen. Bestände, Preise, Lieferzeiten, Kundendaten. Wenn dein Shop nicht weiß, was dein ERP weiß, verlierst du Vertrauen und Geld.
Ist Performance Optimierung schon Custom Development?
Manchmal ja, oft nein. Viele Performance Probleme kommen von Konfiguration, Hosting, zu vielen Plugins, schlecht optimierten Bildern und fehlendem Caching. Custom wird es, wenn du Prozesse umbauen musst, zum Beispiel Checkout Logik, Datenabfragen oder API Flows.
Welche Mindeststandards brauche ich, bevor ich custom baue?
Du brauchst eine Umgebung, in der du sicher testen kannst. Du brauchst einen klaren Release Ablauf. Du brauchst Logs, damit du Fehler findest. Sonst wird jede Weiterentwicklung zum Glücksspiel.
Staging System, Versionsverwaltung, Deploy Prozess, Backups, Monitoring, klare Rollen
Automatisierte Tests, Feature Flags, Lasttests vor Kampagnen
Welche Info brauchst du, um mir eine klare Empfehlung zu geben?
Gib mir drei Zahlen und ich kann schon viel ableiten. Bestellungen pro Tag, Anzahl Systeme, die mit dem Shop reden, und wie viele Plugins du im Einsatz hast. Dann sag mir den einen Prozess, der dich am meisten nervt. Ich wette, da steckt dein Engpass.
Ich habe den Artikel jetzt dreimal gelesen und bin immer noch hin- und hergerissen. Wir sind ein Buchhandel mit Schwerpunkt auf norddeutsche Literatur und regionaler Geschichte. Unser WooCommerce-Shop hat ca. 2.500 Titel, und eigentlich funktioniert er gut. Aber: Wir hätten gerne eine intelligente Empfehlungsfunktion, die nicht nur nach „Kunden kauften auch“ arbeitet, sondern thematisch-inhaltlich verknüpft. Zum Beispiel: Wer sich für die Geschichte des Hamburger Hafens interessiert, bekommt auch Romane empfohlen, die in der Hafencity spielen. Das ist mit Standard-Plugins nicht machbar. Lohnt sich Custom-Development für ein so spezialisiertes Feature, wenn man nur 150-200 Bestellungen im Monat hat?
Schöner Beitrag! Was mir als Grafikdesignerin auffällt: Viele unterschätzen den Unterschied, den ein Custom-Frontend machen kann. Ich arbeite viel mit Onlineshop-Betreibern zusammen, und gerade im Premium-Segment ist ein individuelles Design Gold wert. Standard-Themes sehen oft einfach nach Standard aus – und das merken die Kunden, auch wenn sie es nicht bewusst formulieren können. Wenn du Designermode für 200 Euro das Stück verkaufst, aber dein Shop aussieht wie ein 08/15-Template, dann passt die Markenbotschaft nicht. Allerdings stimme ich dem Artikel zu: Das Backend muss deswegen nicht custom sein. Ein individuelles Frontend auf einem Standard-Backend ist oft der beste Kompromiss zwischen Markenauftritt und Wartbarkeit.
Mega Artikel und mega Diskussion! Ich muss hier eine Erfahrung teilen, die vielleicht dem einen oder anderen hilft. Wir betreiben einen Multi-Channel-Shop für Outdoor-Ausrüstung: eigener Webshop auf Shopware 6, dazu Amazon, eBay und seit Kurzem auch Decathlon Marketplace. Die größte Herausforderung war nicht der Shop selbst, sondern die Synchronisierung über alle Kanäle hinweg.
Wir haben anfangs versucht, das mit Standard-Plugins zu lösen. Das Ergebnis: Überverkäufe, weil der Bestandsabgleich zu langsam war, unterschiedliche Preise auf verschiedenen Plattformen und ein Kundenservice, der nur noch Feuer gelöscht hat. Dann haben wir in eine Custom-Middleware investiert, die alle Kanäle in Echtzeit synchronisiert. Bestände, Preise, Bestellungen – alles wird zentral gesteuert und in Millisekunden aktualisiert.
Die Investition von ca. 35.000 Euro klingt erstmal heftig, aber wir haben vorher monatlich ca. 3.000 Euro an Überverkäufen und manuellen Korrekturen verloren. Nach einem Jahr war das also locker refinanziert. Wer ähnliche Herausforderungen hat, dem empfehle ich den Beitrag zur Multi-Channel-Strategie – da wird gut erklärt, wann sich der Aufwand lohnt.
Ich finde es wichtig, auch mal die Schattenseite zu beleuchten: Custom-Development kann ein echtes Ressourcengrab werden, wenn man es nicht richtig managed. Wir betreiben einen Online-Verlag und haben uns eine individuelle Abo-Verwaltung programmieren lassen. Die Entwicklung allein hat sechs Monate gedauert – doppelt so lang wie geplant. Und danach brauchten wir noch drei Monate Bugfixing, bis das System stabil lief. Die Gesamtkosten lagen am Ende 40% über Budget. Trotzdem bereue ich es nicht, weil die Lösung jetzt exakt unseren Workflow abbildet. Aber: Plant bei Custom-Projekten immer mindestens 30% Puffer ein, sowohl zeitlich als auch finanziell. Alles andere ist naiv.
Klasse Beitrag, der mich stark an unsere eigene Journey erinnert! Ich bin Mitgründer eines Startups, das personalisierte Nahrungsergänzungsmittel online verkauft. Unsere gesamte Geschäftsidee basiert darauf, dass Kunden einen Online-Fragebogen ausfüllen und darauf basierend eine individuelle Produktzusammenstellung erhalten. Das konnte kein Standard-Shop der Welt abbilden – wir brauchten von Tag eins an Custom-Development.
Was wir gelernt haben: Wenn Custom-Development dein Kernprodukt IST und nicht nur ein Nice-to-have, dann lohnt sich die Investition immer. Aber – und das ist entscheidend – man sollte trotzdem auf einer etablierten Plattform aufbauen. Wir nutzen Magento als Basis für Payment, Bestellmanagement und Versand, und haben den Konfigurator als eigenes Modul draufgesetzt. So profitieren wir von den Standard-Updates für alles Nicht-Individuelle.
Was mich noch interessieren würde: Wie gehen andere hier mit dem Thema komplexe Versandmethoden um? Unser individuelles Produkt hat sehr spezielle Versandanforderungen (Kühlkette), und da stoßen wir tatsächlich an die Grenzen der Standard-Versand-Plugins.
Wir betreiben einen kleinen aber feinen Online-Shop für handgefertigte Keramik aus dem Norden. Ehrlich gesagt war die Entscheidung für uns ganz einfach: Mit 60 Produkten und ca. 100 Bestellungen im Monat brauche ich kein Custom-Development. Unser WooCommerce-Shop mit einem schönen Theme und ein paar Standard-Plugins läuft einwandfrei. Was ich aus dem Artikel aber mitnehme, ist der Gedanke, dass man das regelmäßig hinterfragen sollte. Falls wir weiter wachsen, werden wir vielleicht irgendwann an den Punkt kommen, wo individuelle Lösungen Sinn ergeben. Bis dahin gilt für mich: Keep it simple und konzentrier dich auf dein Handwerk!
Als Shopware-Entwickler möchte ich hier eine technische Perspektive einbringen, die oft zu kurz kommt: Die Qualität einer Custom-Entwicklung steht und fällt mit der Architektur. Ich sehe regelmäßig Projekte, bei denen Agenturen den Core des Shopsystems hacken, anstatt saubere Plugins oder Extensions zu entwickeln. Das führt dazu, dass bei jedem Update alles kaputtgeht und die Wartung zum Albtraum wird.
Eine gute Custom-Entwicklung respektiert immer die Architektur des zugrundeliegenden Systems. Bei Shopware 6 bedeutet das: Eigene Plugins, die über die offizielle API arbeiten und sauber von der Core-Logik getrennt sind. Bei Magento 2: Module, die den Dependency-Injection-Container nutzen und Events/Observers statt Core-Overrides verwenden.
Wer in Custom investiert, sollte unbedingt darauf achten, dass der Entwickler diese Prinzipien versteht und befolgt. Sonst hat man zwar kurzfristig eine individuelle Lösung, langfristig aber ein Wartungsproblem. In dem Zusammenhang empfehle ich auch den Beitrag über die Zukunft von Shopware 6, der zeigt, warum saubere Plugin-Entwicklung so wichtig ist.
Toller Artikel, und die Kommentare hier sind Gold wert! Wir sind ein Familienunternehmen in vierter Generation und haben vor zwei Jahren den Sprung in den E-Commerce gewagt. Unser Sortiment – hochwertige Tees und Gewürze aus eigenem Import – ist nicht riesig (ca. 180 Produkte), aber die Beratung dahinter ist extrem wichtig. Wir haben uns bewusst gegen Custom-Development entschieden und stattdessen einen Shopware-Shop mit Standard-Plugins aufgesetzt. Dafür haben wir das gesparte Budget komplett in erstklassigen Content investiert: Videoberatung zu jedem Tee, Zubereitungsanleitungen, Herkunftsgeschichten. Das war für uns die richtige Entscheidung. Nicht jedes Problem braucht eine technische Lösung – manchmal ist Content die bessere Investition.
@Hauke Clausen: Sehr berechtigte Frage! Wir hatten genau diese Situation – unser erster Entwickler ist nach einem Jahr einfach abgetaucht. Seitdem achten wir auf drei Dinge: 1) Der gesamte Quellcode muss in einem Git-Repository liegen, auf das wir Zugriff haben. 2) Jedes Custom-Modul muss sauber dokumentiert sein – nicht nur Kommentare im Code, sondern eine echte technische Dokumentation. 3) Wir arbeiten nur noch mit Agenturen, die auf etablierten Plattformen entwickeln, also Magento, Shopware oder WooCommerce. So kann im Worst Case jeder andere qualifizierte Entwickler den Code verstehen und weiterentwickeln. Einen guten Einstieg in die Thematik gibt auch das Pflichtenheft für E-Commerce-Projekte – da wird genau erklärt, wie man solche Abhängigkeiten von Anfang an vermeidet. Investiert lieber etwas mehr in ordentliche Projektdokumentation, das zahlt sich langfristig aus.
Mich würde mal interessieren, wie die Leute hier ihre Custom-Entwicklungen absichern. Wir sind ein kleines Handwerksunternehmen und verkaufen Werkzeuge online. Die Idee einer individuellen Lösung klingt ja verlockend, aber was passiert, wenn die Agentur pleitegeht oder der Freelancer keine Lust mehr hat? Bei Standard-Plugins kann ich im Notfall wechseln, bei Custom-Code sitzt man erstmal fest. Hat jemand einen guten Ansatz für dieses Risiko? Wir reden hier ja über teilweise fünfstellige Investitionen.
Ich muss hier einfach unsere Erfolgsgeschichte teilen, weil sie so gut zum Artikel passt! Wir betreiben einen Onlineshop für Spielwaren und hatten ein riesiges Problem: Unsere Kunden wollten Spielzeug nach Alter, pädagogischem Wert, Materialart und Interessen filtern können – nicht nur nach Kategorie und Preis. Kein Standard-Filter konnte das abbilden.
Wir haben dann eine Custom-Filterlösung in unseren Magento-Shop integrieren lassen, die auf einem Tag-System basiert. Jedes Produkt wird mit bis zu 30 pädagogisch relevanten Tags versehen, und der Kunde kann frei kombinieren: „Holzspielzeug + 3-5 Jahre + Feinmotorik + unter 30 Euro“. Das Ergebnis war der Wahnsinn: Die durchschnittliche Verweildauer stieg um 45%, die Bounce-Rate sank um 22%, und der Umsatz pro Besucher erhöhte sich um 31%.
Das ist genau der Sweet Spot für Custom-Development: Wenn es ein echtes, messbares Kundenproblem löst, das keine Standardlösung bedienen kann. Übrigens haben wir gleichzeitig auch den Checkout-Prozess optimiert – da allerdings mit Standard-Tools, weil das nichts Individuelles brauchte. Die Mischung macht es!
Was im Artikel leider etwas kurz kommt, ist das Thema laufende Kosten. Klar, eine Custom-Lösung hat einen höheren Anschaffungspreis, aber man vergisst gerne die Folgekosten. Bei uns im Autohaus haben wir einen individuellen Fahrzeugkonfigurator entwickeln lassen. Einmalig hat das 25.000 Euro gekostet. Aber: Jedes Shopware-Update erfordert Anpassungen am Custom-Code, und das sind schnell mal 2.000-3.000 Euro pro Jahr. Dazu kommen Security-Patches, die man auch für den Custom-Teil pflegen muss. Wer eine Custom-Entwicklung plant, sollte mindestens 20-25% der Initialkosten als jährliches Wartungsbudget einplanen. Das wird von vielen unterschätzt.
Endlich mal ein Beitrag, der das Thema differenziert betrachtet, anstatt pauschal „Custom ist immer besser“ zu rufen! Ich bin Marketing-Leiterin bei einem Pharma-Zulieferer, und wir haben eine ziemlich schmerzhafte Reise hinter uns. Unser erster Onlineshop war eine Complete-Custom-Lösung – eigenes Framework, eigenes CMS, eigenes alles. Die Agentur hatte uns versprochen, das sei die ultimative Lösung. Realität: Nach drei Jahren waren die Entwickler weg, die Dokumentation miserabel, und jede kleine Änderung hat Tausende gekostet. Wir haben dann den mutigen Schritt gemacht und alles auf Shopware 6 migriert. 80% unserer Anforderungen konnten wir mit Standard-Plugins abdecken. Für die restlichen 20% – vor allem die Anbindung an unser SAP-System und die branchenspezifische Produktzertifizierung – haben wir dann gezielt Custom-Module entwickeln lassen. Dieser 80/20-Ansatz ist genau das, was im Artikel beschrieben wird, und er funktioniert. Wer vor einem Shop-Relaunch steht, sollte sich wirklich Zeit nehmen, genau zu analysieren, was Standard sein kann und was wirklich individuell sein muss.
@Levke Jansen: Wir hatten das gleiche Problem mit einem Uhren-Konfigurator. Mein Tipp: Bevor du komplett umziehst, lass dir mal ein individuelles Variantenmanagement als WooCommerce-Plugin entwickeln. Das ist deutlich günstiger als ein kompletter Systemwechsel. Bei uns hat das Custom-Plugin ca. 8.000 Euro gekostet, ein Wechsel zu Magento wäre locker das Fünffache gewesen. Natürlich kommt es auf die Komplexität an, aber gerade bei WooCommerce kann man mit gezielten Erweiterungen sehr weit kommen. Das setzt allerdings voraus, dass man einen Entwickler findet, der sowohl WooCommerce als auch das Domainwissen mitbringt.
Danke für den Artikel! Wir stehen gerade genau vor dieser Entscheidung. Unser Schmuck-Onlineshop läuft aktuell auf WooCommerce und wir merken, dass wir an Grenzen stoßen – vor allem beim Thema Produktdarstellung und Variantenmanagement. Jedes Schmuckstück gibt es in verschiedenen Materialien, Größen und mit optionaler Gravur. Die Standard-Varianten in WooCommerce werden bei 6.000+ Kombinationen einfach unübersichtlich. Hat jemand ähnliche Erfahrungen? Bevor wir eine Custom-Lösung beauftragen, überlegen wir auch, ob ein Systemwechsel sinnvoll wäre. Den Shopsystem-Vergleich hier auf der Seite fand ich schon sehr aufschlussreich.
Guter Beitrag. Ich muss aber eine Lanze für Standard-Shops brechen: Wir betreiben seit fünf Jahren einen erfolgreichen Shopware-Shop für Gartenbedarf mit über 8.000 Artikeln. Komplett Standard, keine einzige Custom-Entwicklung. Wir machen siebenstellige Umsätze. Der Trick ist, dass wir unsere Geschäftsprozesse an die Software angepasst haben, nicht umgekehrt. Klar, manchmal wäre eine individuelle Lösung eleganter, aber die Kosten-Nutzen-Rechnung hat bei uns nie gestimmt. Bevor man in Custom investiert, sollte man sich ehrlich fragen: Ist mein Prozess wirklich so einzigartig, oder bilde ich mir das nur ein?
Wunderbar geschriebener Artikel! Was mich besonders anspricht, ist der Punkt zur Skalierungsfähigkeit. Wir betreiben einen Online-Shop für nachhaltige Kosmetik und sind in den letzten zwei Jahren von 200 auf über 3.000 Bestellungen pro Monat gewachsen. Unser ursprünglicher WooCommerce-Shop mit Standard-Theme war ab ca. 1.500 Bestellungen am Limit. Nicht nur technisch, sondern vor allem prozessual: Bestandsabgleich, Retourenmanagement, Multi-Channel-Anbindung an Amazon und Avocadostore – das alles manuell zu handhaben war ein Albtraum.
Wir haben uns dann entschieden, das Backend komplett custom entwickeln zu lassen, während das Frontend auf einem optimierten Standard-Theme basiert. Dieser hybride Ansatz hat sich als goldrichtig erwiesen. Die automatisierte ERP-Integration allein spart uns pro Woche mindestens 15 Arbeitsstunden. Mein Learning: Investiert in die unsichtbare Infrastruktur, nicht in ein fancy Frontend. Eure Kunden sehen den hübschen Shop, aber euer Team leidet unter schlechten Prozessen im Hintergrund.
Der Artikel trifft einen wunden Punkt. Als Geschäftsführer eines kleinen Sportartikel-Shops mit rund 400 Produkten musste ich die bittere Erfahrung machen, dass Custom-Development nicht automatisch besser ist. Wir haben uns von einem Freelancer ein komplett individuelles Checkout-System bauen lassen, weil wir dachten, das Standard-Checkout sei nicht gut genug. Das Ergebnis war ein fehleranfälliges System, das kein anderer Entwickler anfassen wollte. Mittlerweile sind wir zurück bei der Standard-Lösung, haben die aber sauber optimiert. Manchmal ist weniger wirklich mehr.
@Jörn Matthiesen: Ich kann dir aus eigener Erfahrung antworten, weil wir im B2B-Bereich exakt das gleiche Thema hatten. Bei uns ging es um individuelle Staffelpreise für über 500 Geschäftskunden in der Industriezulieferung. Wir haben uns letztlich für eine Custom-Lösung auf Magento-Basis entschieden, die direkt an unser SAP angebunden ist. Die Preislisten werden nachts automatisch synchronisiert, und jeder Kunde sieht beim Login sofort seine individuellen Preise. Der Aufwand hat sich innerhalb von acht Monaten amortisiert, weil wir vorher drei Mitarbeiter brauchten, die manuell Angebote erstellt haben. Grundsätzlich würde ich für komplexe B2B-Anforderungen immer empfehlen, sich die B2B-Funktionalitäten in Magento genauer anzuschauen – da ist vieles nativ schon sehr mächtig, und die Custom-Lücken lassen sich gezielt schließen.
Interessante Diskussion hier! Ich habe eine konkrete Frage an die Runde: Wir sind ein B2B-Großhändler für Sanitärbedarf und brauchen dringend kundenspezifische Preislisten im Shop. Jeder unserer 350 Geschäftskunden hat individuelle Rahmenverträge mit unterschiedlichen Rabatten. Die Standard-Kundengruppen in Shopware reichen dafür bei Weitem nicht aus. Hat jemand Erfahrung, ob sich dafür eine Custom-Entwicklung lohnt, oder gibt es mittlerweile brauchbare Extensions, die sowas abbilden können? Unser Budget ist leider begrenzt, und ich will nicht in eine Sackgasse investieren.
Super Beitrag, der genau den Nerv trifft! Ich leite den E-Commerce-Bereich eines mittelständischen Möbelhauses hier in Lübeck. Wir haben uns vor drei Jahren ganz bewusst für Magento 2 als Basis entschieden und dann schrittweise Custom-Module entwickeln lassen – unter anderem einen 3D-Raumplaner, der es Kunden ermöglicht, unsere Möbel virtuell in ihrem Wohnzimmer zu platzieren. Dieses Feature hat kein Standard-Plugin der Welt geliefert, und es ist heute unser absolutes Alleinstellungsmerkmal. Der durchschnittliche Warenkorbwert bei Kunden, die den Raumplaner nutzen, liegt 67% über dem Durchschnitt. Das zeigt: Wenn Custom-Development auf ein echtes Kundenbedürfnis einzahlt, ist der ROI enorm. Gleichzeitig nutzen wir für alles andere – Payment, Versand, Newsletter – Standard-Extensions, weil man das Rad nicht neu erfinden muss. Für alle, die sich für eine professionelle Magento-Entwicklung interessieren, kann ich nur empfehlen, sich eine Agentur zu suchen, die diesen hybriden Ansatz versteht. Nicht alles muss custom sein, aber die entscheidenden Touchpoints schon!
Hätte ich diesen Beitrag mal vor zwei Jahren gelesen! Wir haben uns damals für eine komplett individuelle Lösung entschieden, weil uns eine Agentur eingeredet hat, dass wir damit „zukunftssicher“ seien. Ergebnis: Ein überteuertes System, das kaum einer im Team bedienen kann, furchtbar schlecht dokumentiert ist und bei jedem Update Probleme macht. Für unseren Elektronik-Shop mit 800 Produkten hätte eine gut konfigurierte Standardlösung mit ein paar gezielten Erweiterungen vollkommen gereicht. Das hat uns am Ende fast 60.000 Euro gekostet, die wir besser in Marketing hätten stecken können. Leute, überlegt euch dreimal, ob ihr wirklich Custom braucht oder ob euer Ego das will!
Spannender Artikel! Wir haben letztes Jahr unseren Feinkost-Shop von einer reinen WordPress/WooCommerce-Lösung auf ein Custom-Frontend mit Headless-Ansatz umgestellt. Der Grund war, dass wir eine extrem schnelle mobile Darstellung brauchten – viele unserer Kunden bestellen mittags vom Smartphone aus. Die Ladezeiten haben sich von 3,8 auf 1,2 Sekunden verbessert, und die mobile Conversion ist um 28% gestiegen. Wer sich für den Headless-Commerce-Ansatz interessiert, dem kann ich nur empfehlen, sich das Thema genau anzuschauen. Allerdings muss man auch sagen: Die laufenden Wartungskosten sind höher als vorher.
Als IT-Berater, der seit über 15 Jahren E-Commerce-Projekte begleitet, kann ich die Kernaussage des Artikels nur bestätigen: Die Entscheidung zwischen Custom-Development und Standard-Shop ist keine binäre. In der Praxis sehe ich bei meinen Kunden fast immer hybride Ansätze. Man startet mit einem soliden Standard-Shopsystem wie Magento oder Shopware und erweitert es dann gezielt dort, wo die individuellen Geschäftsprozesse es erfordern. Was ich allerdings viel zu oft erlebe: Unternehmen investieren in Custom-Development an den falschen Stellen. Sie lassen sich einen fancy Produktkonfigurator bauen, obwohl ihr eigentliches Problem im Checkout-Prozess liegt. Oder sie pumpen Geld in ein individuelles Frontend, während die Anbindung an die Warenwirtschaft noch über manuelle CSV-Importe läuft. Mein dringender Rat: Bevor ihr auch nur einen Euro in Individualentwicklung investiert, macht eine saubere Prozessanalyse. Wo verliert ihr tatsächlich Kunden? Wo entstehen manuelle Aufwände, die sich automatisieren lassen? Wo steht die Standardlösung wirklich im Weg? Erst wenn ihr das sauber analysiert habt, könnt ihr fundiert entscheiden, wo Custom-Development echten ROI liefert.
Ich bin ehrlich gesagt noch unschlüssig. Wir haben einen mittelgroßen Textilshop mit ca. 1.200 Artikeln und nutzen Shopware 6 mit Standard-Plugins. Bisher funktioniert das ganz okay, aber unser Warenwirtschaftssystem macht uns zunehmend Probleme bei der Synchronisierung. Die Frage ist halt immer: Ab wann rechtfertigen die Probleme eine teure Individualentwicklung? In dem Zusammenhang habe ich auch den Beitrag über ERP-Integration in Onlineshops gelesen – sehr hilfreich! Kann jemand aus eigener Erfahrung sagen, ab welchem Umsatzvolumen sich eine Custom-Schnittstelle zur Warenwirtschaft wirklich lohnt?
Vielen Dank für diesen detaillierten Beitrag! Wir betreiben seit 2019 einen Onlineshop für maritime Dekoration und haben anfangs auf eine reine Standardlösung mit WooCommerce gesetzt. Das lief zwei Jahre lang wunderbar, bis wir angefangen haben, individuell konfigurierbare Produkte anzubieten – zum Beispiel personalisierte Holzschilder mit Gravur. Da sind wir mit den Standard-Plugins an massive Grenzen gestoßen. Der Produktkonfigurator, den wir brauchten, existierte schlicht nicht als fertige Lösung. Am Ende haben wir uns für eine Custom-Entwicklung entschieden, und obwohl die Investition anfangs wehgetan hat, war das der Gamechanger für unser Geschäft. Die Conversion-Rate bei konfigurierbaren Produkten ist um 34% gestiegen, weil der Bestellprozess endlich intuitiv war. Mein Rat an alle, die vor dieser Entscheidung stehen: Macht euch vorher ein ehrliches Bild davon, wo eure Standardlösung wirklich an Grenzen stößt, und investiert dann gezielt in Custom-Development genau an diesen Schmerzpunkten.