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.
Danke für diesen differenzierten Beitrag! Ich arbeite in der Geschäftsleitung eines regionalen Bioladens mit angeschlossenem Onlineshop. Für uns war der entscheidende Moment, als wir Abo-Boxen einführen wollten – wöchentlich individuell zusammengestellte Obst- und Gemüsekisten. Die Standard-Abo-Plugins konnten das nicht abbilden, weil jede Box saisonabhängig anders bestückt wird und der Kunde vorher An- und Abwählen können muss. Die Custom-Lösung hat zwar 12.000 Euro gekostet, aber sie generiert mittlerweile 30% unseres Onlineumsatzes. Das war die beste Investition, die wir je getätigt haben. Entscheidend war, dass wir vorher genau wussten, was wir wollten – ein detailliertes Pflichtenheft hat uns vor Scope Creep bewahrt.
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.
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.
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!
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.
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.
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.
@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.
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?
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.
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.
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!
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.
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.