Die Entscheidung über die Wahl der E-Commerce-Plattform landet fast immer an derselben Stelle: auf dem Schreibtisch der IT-Abteilung oder eines externen technischen Dienstleisters. Die Frage „worauf sollen wir den Shop aufbauen" klingt technisch, also delegiert man sie ganz natürlich an Techniker. Das ist einer der teuersten Kategorisierungsfehler, die wir im Mid-Market sehen.
„Welche Plattform" ist eine abgeleitete Frage. Sie ergibt sich daraus, welches Geschäft Sie für die nächsten fünf Jahre aufbauen: B2B oder D2C, ein Markt oder Expansion, ein Katalog mit zweitausend oder sechzigtausend SKUs, ein Marketing- oder ein Technikteam. Die IT beantwortet diese Frage anders, als das Business sie beantworten würde — und zwar systematisch, nicht zufällig. Im Folgenden zeigen wir, warum das so ist, drei anonymisierte Fälle, in denen die IT für das Business entschieden hat, sowie einen einfachen Rahmen, der diese Entscheidung in die richtige Reihenfolge bringt.
Warum diese Entscheidung überhaupt bei der IT landet
Die Wahl einer Plattform sieht wie ein Ingenieursproblem aus. Man muss Stacks, APIs, Performance und Hosting-Modelle vergleichen. Eine Geschäftsführung, die sich in diesen Themen nicht sicher fühlt, gibt die Entscheidung gern an Menschen ab, die sich darin sicher fühlen. Das Problem ist: Damit gibt sie auch die Gewichtungen ab — und es sind die Gewichtungen, nicht die Kriterienliste selbst, die das Ergebnis bestimmen.
Die teuerste Investition im E-Commerce ist ein Shop, den man nach einem Jahr neu schreiben muss, weil die gewählte Architektur dem Wachstum des Geschäfts nicht standgehalten hat. Eine Plattform wählt man für 5–7 Jahre Produktlebensdauer, nicht für den nächsten Launch. Und der Horizont, auf dem sich diese Entscheidung am besten bewerten lässt — Umsatzmodell, Roadmap, Passung zum Team — ist per Definition geschäftlich, nicht technisch.
Worauf die IT optimiert (und warum das nicht dasselbe ist wie das Business)
Eine gute IT-Abteilung wählt nicht aus böser Absicht falsch. Sie wählt, was eine IT-Abteilung schätzt — und sie schätzt Dinge, die aus ihrer Perspektive real und sinnvoll sind:
Kontrolle und Flexibilität. Vollständiger Zugriff auf den Code, keine SaaS-Beschränkungen, die Möglichkeit, alles zu bauen. Open Source auf dem eigenen Server schlägt ein geschlossenes Ökosystem.
Kein Vendor-Lock-in und keine Lizenzgebühren. Eine Lizenz von 2.200 USD monatlich plus ein Prozentsatz vom Umsatz sieht für einen Ingenieur nach Verschwendung aus, wenn „dasselbe" auf einer kostenlosen Engine möglich ist.
Ein bekannter Stack. Ein Team, das seit Jahren mit WordPress oder Symfony arbeitet, tendiert naturgemäß zu dem, was es schon zu betreiben weiß.
Technische Eleganz. Headless, saubere Architektur, ein modernes Frontend — Dinge, die im Code Review gut aussehen.
Jeder dieser Werte ist berechtigt. Keiner davon ist identisch mit dem, was über den Umsatz entscheidet: Time-to-Market, Betriebskosten über einen Dreijahreshorizont und die Frage, wer den Shop tatsächlich täglich bedient.
In unserem Plattformvergleich bewerten wir jede Engine in sechs Dimensionen: Admin-Panel, Konfiguration, Entwicklungsmöglichkeiten, Performance, SEO und Sicherheit. Die IT legt instinktiv das größte Gewicht auf „Entwicklungsmöglichkeiten", denn das ist ihre Welt. Das Business sollte „das Admin-Panel" am stärksten gewichten, denn davon hängt ab, ob das Marketing eine Kampagne selbst startet oder für jede Änderung ein Ticket an einen Entwickler stellt. Dieses eine verschobene Gewicht genügt, damit ein anderes Ergebnis herauskommt.
Drei Fälle, in denen die IT für das Business entschieden hat
Die folgenden Geschichten sind zusammengesetzte, anonymisierte Archetypen, keine konkreten Kunden — und die Umsatzzahlen sind illustrativ. Jede davon ist jedoch ein Muster, das sich im Mid-Market regelmäßig wiederholt.
Fall 1: Over-Engineering für ein einfaches D2C-Geschäft
Ein Hersteller von Naturkosmetik, rund 12 Mio. PLN Jahresumsatz, D2C-Vertrieb, ein einfacher Katalog mit bis zu zweitausend SKUs, Expansionspläne in die DACH-Märkte. Die IT empfiehlt eine Custom-Lösung auf Symfony/Sylius: „volle Kontrolle, null Lock-in, wir bauen genau das, was wir wollen".
Die geschäftliche Realität war eine andere. Es ist eine Marketing-, keine Technologiemarke — ohne internes PHP-Team, dafür mit dem Anspruch, schnell nach Deutschland und Österreich zu kommen. Sylius kann alles, aber Customizing braucht Zeit: eine Umsetzung auf dieser Engine dauert typischerweise 16–22 Wochen, während Shopify Plus einen produktiven Shop in 8–14 Wochen liefert. Das Sylius-Panel ist für Entwickler gestaltet, das Shopify-Panel — für Marketer. Das Ergebnis: Jede Kampagne und jede Änderung auf der Website brauchte einen Entwickler, und Multi-Currency sowie Multi-Language, die in Shopify Plus fertig mitkommen, mussten nachgebaut werden. Die Marke verlor die Saisons, in denen sie in DACH längst hätte verkaufen sollen.
Die IT hat auf Kontrolle optimiert. Das Business brauchte Time-to-Market und die Eigenständigkeit des Marketings.
Fall 2: die SaaS-Decke unter der Last von B2B
Ein Distributor von Industrieteilen, rund 40 Mio. PLN Umsatz, über sechzigtausend SKUs, individuelle Preislisten pro Geschäftspartner, Lieferantenkredit, ein aus dem ERP gespeister Katalog. Diesmal entschied die IT umgekehrt: Shopify Plus, „weil es SaaS ist, wir müssen keine Infrastruktur betreiben und starten schnell".
Shopify Plus ist hervorragend für D2C, aber B2B ist nicht seine Stärke. Individuelle Preislisten, Kreditlimits und Vertragslogik erfordern dort Apps und Custom-Entwicklung — Dinge, die Sylius nativ mitbringt. Dazu kommt: Ein Katalog über fünfzigtausend SKUs kratzt an den Komfortgrenzen von SaaS. Jede B2B-Regel wurde zu einer weiteren kostenpflichtigen App, und die Rechnung summierte sich: 2.200 USD Lizenz monatlich, dazu ein App-Stack (im Mid-Market typischerweise 200–800 USD) und Transaktionsgebühren. Die realen Betriebskosten eines Shops mit rund 20 Mio. PLN Umsatz können 15.000–25.000 PLN monatlich erreichen — und ein Modell, das „günstiger, weil ohne Server" sein sollte, erwies sich als teurer und im Kern fragil.
Die IT hat die operative Einfachheit für sich selbst optimiert. Das Business war von Grund auf B2B und brauchte eine Plattform, die Preislisten und Lieferantenkredit als Standard behandelt und nicht als Ausnahme.
Fall 3: der bekannte Stack anstelle einer Roadmap
Ein Möbelhersteller, rund 15 Mio. PLN Jahresumsatz, ein wachsender Katalog mit Produktkonfiguration (Maße, Stoffe, Varianten), Pläne für den Einstieg in Marketplaces. Die IT schlägt WooCommerce auf WordPress vor: „wir kennen WordPress, wir haben es in anderen Projekten, für alles gibt es ein Plugin".
Am Anfang funktionierte es. Das Problem trat mit dem Wachstum auf. WooCommerce ist der günstigste Einstieg, doch die Flexibilität bezahlt man mit dem Betrieb — Performance und Sicherheit sind seine schwächsten Dimensionen, und jeder neue Bedarf bedeutet ein weiteres Plugin und eine weitere Fehlerfläche. Mit wachsendem Katalog und Traffic wurde der Shop langsamer, und die Liste der zu pflegenden Plugins blähte sich auf. Nach etwas mehr als einem Jahr war das Business genau bei dem angekommen, was am teuersten ist: beim Neuschreiben der Plattform — denn die gewählte Engine passte zur Komfortzone des IT-Teams und nicht zur Roadmap der kommenden Jahre.
Die IT hat auf die Vertrautheit mit dem Werkzeug optimiert. Das Business brauchte eine Plattform, die zu dem passt, wo es in drei Jahren steht, nicht zu dem, was das Team schon kann.
Eine Plattform ist keine Technologieentscheidung mit geschäftlichen Konsequenzen. Sie ist eine Geschäftsentscheidung mit technologischen Konsequenzen. Die Reihenfolge ist keine Kosmetik — sie bestimmt das Ergebnis.
Wie diese Entscheidung aussehen sollte
Das Prinzip ist einfach: zuerst die Kriterien und ihre Gewichtungen, dann die Plattformnamen. Business und IT an einem Tisch — aber mit klarer Rollenteilung. Bevor irgendwer das Wort „Shopify" oder „Sylius" ausspricht, beantworten Sie sieben Fragen:
Geschäftsmodell. B2B, D2C oder Hybrid? Das entscheidet über Preislisten, Lieferantenkredit und Checkout — und verengt die Liste meist von selbst auf zwei Plattformen.
Roadmap für 3–5 Jahre. Geografische Expansion? Neue Kanäle und Marketplaces? Auf wie viele SKUs wächst der Katalog? Eine Plattform wählt man für den Zielzustand, nicht für den Startzustand.
TCO, nicht der Implementierungspreis. Lizenz plus Apps plus Betrieb plus Kosten (und Verfügbarkeit) von Entwicklern über drei Jahre. Eine kostenlose Engine ist manchmal die teuerste.
Time-to-Market. Wie viel Zeit das Business realistisch hat, um zu starten und zu iterieren.
Wer den Shop täglich bedient. Marketing oder das Technikteam? Davon hängt ab, ob das Panel für Marketer sein muss oder für Entwickler sein darf.
Verfügbarkeit von Kompetenzen. Können wir diesen Stack betreiben? Symfony-Entwickler sind in Polen Mangelware — eine großartige Plattform ohne Menschen für ihren Betrieb ist ein Risiko, kein Vorteil.
Robustheit gegenüber Veränderung. Wie stark bindet uns die Wahl die Hände, wenn das Business die Richtung wechselt.
Die Rolle der IT in diesem Prozess ist unverzichtbar — aber es ist die Rolle des Experten, nicht des Entscheiders. Die IT bewertet die Plattformen der Shortlist hinsichtlich Machbarkeit, Integrationen, Performance und Sicherheit und benennt rote Flaggen. Das Business legt die Gewichtungen der Kriterien fest und bestimmt den Gewinner. Wenn die IT das Recht erhält, die Gewichtungen festzulegen, verschiebt sich die Entscheidung unmerklich in Richtung dessen, was die IT schätzt — und kommt in Form der drei Geschichten oben ins Unternehmen zurück.
Passung der Plattform zum Geschäftsprofil
Es gibt keine „beste Plattform" — es gibt die Plattform, die am besten zu einem konkreten Profil passt. So sieht das Mapping aus, das wir am häufigsten verwenden (den vollständigen, sechsdimensionalen Vergleich von neun Engines finden Sie in unseren Plattform-Rankings):
GeschäftsprofilWas wir üblicherweise empfehlenWarumD2C, einfacher Katalog, EU-Expansion, MarketingteamShopify PlusMarkteintritt in 8–14 Wochen, Multi-Currency und Multi-Language fertig, Panel für MarketerB2B, individuelle Preislisten, Lieferantenkredit, ERP, 10–100k SKUSyliusB2B-Logik und Custom nativ, volle Kontrolle über den Code, Headless-ModusMid-Market in PL/EU, moderates BudgetPrestaShopIn Polen verbreitet, gut für den Mid-Market, günstiger als Enterprise-SaaSKleiner/mittlerer Shop, minimales StartbudgetWooCommerceDer günstigste Einstieg — aber man muss mit den Kosten für Betrieb und Plugins rechnen
Zwei unserer Projekte zeigen, wie das bei richtiger Passung funktioniert: Shopify Plus für die D2C-Marke Topeshop, wo die Migration von PrestaShop die Konversion um 58% erhöhte — sowie Sylius für B2B, etwa der Produktkonfigurator bei KMK Klinkier. In beiden Fällen entschied das Geschäftsprofil über die Plattform, nicht die Stack-Präferenz.
Fazit
Die Wahl einer E-Commerce-Plattform ist eine Geschäftsentscheidung mit technischen Konsequenzen — nicht umgekehrt. Die IT ist darin als Stimme für Machbarkeit und Risiko unverzichtbar, doch wenn sie das Recht erhält, die Gewichtungen festzulegen, optimiert sie systematisch auf Kontrolle, den bekannten Stack und Eleganz statt auf Time-to-Market, TCO und Passung zum Team. Legen Sie die Kriterien vor den Plattformnamen fest, setzen Sie Business und IT mit klarer Rollenteilung an einen Tisch — und Sie vermeiden das teuerste Szenario, nämlich das Neuschreiben des Shops nach achtzehn Monaten.
Wenn die Plattformentscheidung noch vor Ihnen liegt, ist ein unabhängiges Audit und eine Plattformberatung ein guter erster Schritt — am Ende steht ein Dokument mit einer Empfehlung für die Geschäftsführung, basierend auf dem Profil Ihres Geschäfts und nicht auf der Präferenz einer der Seiten. Wir gehen das gern gemeinsam mit Ihnen durch; schreiben Sie uns über unsere Kontaktseite.