Make or Buy im E-Commerce: Wann zahlt sich Custom wirklich aus?

"Können wir den Online-Shop so bauen dass er genau unsere Anforderungen erfüllt?" Die Antwort ist ja. Die bessere Frage ist: Sollten wir es?

Make or Buy ist eine alte Entscheidung. Sie wird jede Dekade wiederbelebt und die Antwort ist meistens: Buy. Aber in E-Commerce gibt es echte Fälle wo Custom Sinn macht. Wir sortieren das aus.

Inhalt

1. Make oder Buy: Die Grundoption
2. Wann zahlt sich Eigenentwicklung aus?
3. Die versteckten Kosten von Custom-Code
4. Der Faktor "Maintenance"
5. Build, Buy oder Composable?
6. Fazit: Die 30%-Regel ist dein Kompass

Make oder Buy: Die Grundoption

Buy bedeutet: Du nutzt eine Standard-Plattform. Shopware, Shopify, WooCommerce, Magento. Die Plattform bringt 80% deiner Features mit. Die restlichen 20% adaptierst du.

Vorteile:

• Schneller live. 3-6 Monate statt 12-18 Monate.
• Geringeres Risiko. Tausende andere Shops laufen auf der Plattform.
• Einfacher zu pflegen. Regelmäßige Updates, kein Tech-Schulden.

Nachteile:

• Manche Prozesse musst du an die Plattform anpassen, nicht umgekehrt.
• Die Plattform limitiert dich in der Flexibilität.

Make bedeutet: Du baust die Komponenten (Frontend, Backend, Checkout, Integrations) selbst. Mit React, Vue, Node.js, Python, was auch immer.

Vorteile:

• Volle Kontrolle. Jede Anforderung ist machbar.
• Keine Abhängigkeit von Plattform-Updates.
• Du baust genau das was du brauchst, nichts mehr.

Nachteile:

• 2-3x teurer in der Entwicklung.
• Die Verantwortung für Stabilität liegt bei dir.
• Nach dem Launch brauchst du ein eigenes Team das den Code pflegt.

Die meisten Projekte sollten Buy sein. Aber es gibt legitime Fälle für Make.

Wann zahlt sich Eigenentwicklung aus?

Szenario 1: Du brauchst Custom-Logik die 30%+ des Systems ausmacht

Beispiel: Ein B2B Hersteller mit Kundengruppen-Pricing, individuellen Katalogen pro Kunde, komplexen Freigabeprozessen und automatischen Nachbestellungen basierend auf Verbrauchsprognosen.

Eine Standard-Plattform ist nicht schlecht. Aber sie zwingt dich in Kompromisse. Der Checkout funktioniert nicht wie du ihn brauchst. Das Reporting ist beschränkt. Die Anbindung an dein ERP-System ist behelfsmäßig.

Wenn du Custom baust, optimierst du für dein Business. Das zahlt sich auf längere Zeit aus.

Budget: Ab 150.000+ EUR für ein solides Custom-System. Zeitrahmen: 12-18 Monate.

ROI: Wenn die Custom-Logik dir 5% zusätzlichen Umsatz bringt (oder 10% Effizienz-Gewinn), rechnet sich das in 2-3 Jahren.

Szenario 2: Du brauchst extreme Performance oder Skalierung

Ein Online-Marktplatz mit Millionen von Produkten, tausend Verkäufern, komplexen Suchalgorithmen.

Eine Standard-E-Commerce-Plattform ist nicht gebaut für diese Skalierung. Nicht unmöglich, aber der Stack wird behelfsmäßig.

Wenn du Custom baust, optimierst du von Grund auf für deinen Use Case. Die Datenbank-Schemas. Die Caching-Strategie. Die Frontend-Architektur.

Budget: Ab 200.000+ EUR. Zeitrahmen: 18-24 Monate.

ROI: Wenn die Performance-Optimierung dir spürbar mehr Umsatz bringt (weil der Checkout schneller ist, die Conversion Rate steigt), dann ist das eine sehr gute Investition.

Szenario 3: Du brauchst Integrationen die keine Plattform anbietet

Beispiel: Ein Hersteller der seine Produktion direkt an den Shop anbindet. Wenn ein Kunde bestellt, startet direkt die Produktion. Das braucht Echtzeit-Synchronisation zwischen Shop und Produktions-ERP.

Keine Standard-Plattform kann das von Haus aus. Also baust du Custom.

Budget: Ab 50.000+ EUR. Zeitrahmen: 6-12 Monate.

ROI: Wenn dich das 3 Tage Produktions-Vorlaufzeit spart und mehr Flexibilität gibt, zahlt sich das schnell aus.

In allen drei Szenarien: Custom braucht eine gute Begründung. Es reicht nicht zu sagen "wir wollen total flexibel sein". Du brauchst konkrete Features die du mit Buy nicht hinbekommst.

Die versteckten Kosten von Custom-Code

Das wird oft unterschätzt.

1. Die Entwicklung ist nur 50% der Kosten

Jemand muss den Code schreiben. Das kostet. Aber nach dem Launch kommt die echte Arbeit:

• Bug-Fixes: Im ersten Jahr noch Bugs. 20% extra Aufwand.
• Performance-Optimierung: Der Code läuft, aber nicht schnell genug. 10-15% extra.
• Feature-Requests: "Das Feature war nicht in den Anforderungen, aber wir brauchen es jetzt." 20% extra.

Realistisch: Ein Custom-Projekt das 100k kostet und dann live geht, hat oft noch 50k Kosten im ersten Jahr bis das System wirklich stabil ist.

2. Abhängigkeits-Probleme

Du nutzt 20 Open-Source Libraries. Drei davon werden nicht mehr gepflegt. Eine hat eine Sicherheitslücke. Eine andere ist inkompatibel mit der neuen Node-Version.

Das ist 20 Stunden Arbeit um alle Dependencies zu aktualisieren. Das kostet 2.000-3.000 EUR. Jedes Jahr.

Mit Buy: Das macht die Plattform. Shopware aktualisiert ihre Dependencies. Du musst nur Shopware updaten.

3. Team-Abhängigkeit

Der Senior der den Code geschrieben hat, geht. Jetzt sitzt du mit Code der nur ein anderer Senior versteht. Und die sind knapp auf dem Markt.

Das ist ein echtes Risiko. Mit Buy: Der nächste Junior Developer kann eine Shopware-App bearbeiten.

4. Opportunitätskosten

Statt mit Custom zu jonglieren, könntest du mit einer Standard-Plattform 2x schneller neue Features launchen.

Konkret: Ein Feature braucht auf Custom 3 Wochen. Auf Standard-Plattform 1 Woche. Das ist 2 Wochen Zeitvorteil jedes mal.

Über 3 Jahre: 20+ Features. Das sind 40 Wochen Vorsprung. Das ist 4 Features die deine Konkurrenz dir voraus sind.

Das ist ein sehr großer Kostenfaktor.

Der Faktor "Maintenance"

Das ist der entscheidende Punkt.

Mit Buy: Du holst dir eine Agentur wenn dein System Probleme hat oder wenn du eine große Feature willst. Sonst läuft es.

Mit Make: Du brauchst nach dem Launch ein eigenes Team (oder eine engagierte Agentur) die das System pflegt und weiterentwickelt.

Das bedeutet im Jahr 2-3 nach Launch: Ab 30.000+ EUR pro Jahr für Maintenance. Ab 50.000+ EUR für aktive Entwicklung von neuen Features.

Das ist der Grund warum viele Shops die ein Custom-System gebaut haben nach 2-3 Jahren realisieren: "Das hätte mit einer Standard-Plattform weniger teuer sein können."

Build, Buy oder Composable?

Es gibt auch einen mittleren Weg: Composable Commerce.

Das bedeutet: Du nutzt eine API-basierte Plattform als Backend (Shopware, Commercetools) und baust dein eigenes Frontend (Vue.js, Next.js). Mehr über diesen Ansatz im Artikel Composable Commerce.

Vorteile:

• Du kriegst die Backend-Stabilität von der Plattform.
• Du kriegst vollständige Frontend-Kontrolle.
• Die Kosten sind geringer als Full-Custom.

Nachteile:

• Du brauchst Frontend-Expertise.
• Du brauchst Know-how wie APIs funktionieren.

Das ist oft der beste Kompromiss für B2B oder komplexe B2C.

Budget: Ab 80.000+ EUR. Zeitrahmen: 6-12 Monate. Maintenance: Niedriger als Full-Custom, höher als Buy.

Fazit: Die 30%-Regel ist dein Kompass

Martins zentrale Regel: die 30%-Regel

Die 30%-Regel ist eine Architektur-Entscheidung, keine Make-or-Buy-Entscheidung. Sie gilt für JEDES System.

• Unter 30% Custom: Nutze Standard. Passe deinen Prozess an die Plattform an wenn nötig. Das ist meist eine "Buy"-Entscheidung.
• 30-60% Custom: Schau deine Architektur an. Headless Frontend? Microservices daneben? Dann kannst du trotzdem Standard-Plattformen nutzen, aber anders strukturieren. Die Architektur ändert sich, nicht die Plattform.
• Über 60% Custom: Dann zahlt sich Partial-Custom oder Full-Custom aus. Aber das ist selten und sollte sehr begründet sein.

Das ist nicht "Shopware vs. Shopify". Das ist: Wenn mehr als 30% Custom nötig ist, ändert sich deine Architektur (Headless, Microservices), nicht deine Plattform-Wahl. Das ist die zentrale Erkenntnis.

Die wichtigste Frage die du stellen musst: "Baut jeder andere in der Branche das auch Custom? Oder nur wir?"

Wenn nur du es brauchst, ist es wahrscheinlich zu spezifisch. Wenn deine ganze Branche das braucht, dann ist ein neuer Standard am entstehen und Custom kann Sinn machen.