Ein neues Backend-Feld für Mehrsprachigkeit ist schnell angelegt. Der Teil, der danach Monate dauert…
Bauen, Kaufen oder Komponieren: Wie ihr einen Produktkonfigurator betreibt, ohne eure Storefront zu binden
Fast jede Konfigurator-Diskussion endet als Build-vs-Buy-Frage, und die meisten Teams behandeln sie wie eine einmalige Weiche: entweder eigene Logik schreiben oder eine Vendor-Lösung installieren. Diese Sichtweise übersieht die Option, die eine Storefront über mehrere Jahre tatsächlich schützt, Komponieren. Statt zu fragen, ob ihr den Konfigurator baut oder kauft, ist die bessere Frage, wo der Konfigurationszustand, die Preislogik und die Render-Ebene jeweils leben, und ob sich einer dieser Teile bewegen lässt, ohne dass ihr neu baut.
Dieser Beitrag behandelt genau diese Entscheidungsachse. Wenn ihr Core Web Vitals bei einem bestehenden Konfigurator reparieren wollt, deckt unser Beitrag zu Konfiguratoren und Core Web Vitals clientseitigen Optionszustand, Preisberechnung und Layout-Shifts ab. Wenn ihr einen Konfigurator konkret in eine Magento-Storefront einbaut, geht der Magento-Integrationsvergleich native Konfiguration, Widgets und eine entkoppelte Frontend-Ebene durch. Dieser Beitrag steht über beiden: Es geht darum, wie ihr die Bauen-Kaufen-Komponieren-Entscheidung so trefft, dass die Antwort auch nach eurem nächsten Backend-Wechsel noch trägt.
Wo Konfigurator-Lock-in tatsächlich entsteht
Lock-in durch einen Konfigurator zeigt sich selten als einzelne Vertragsklausel. Er entsteht an vier Stellen, und jede kann sich unabhängig von den anderen bewegen:
- Konfigurationsregeln: welche Optionen zusammen gültig sind, welche Kombinationen ausgeschlossen sind, wie Abhängigkeiten kaskadieren (wählt jemand diesen Stoff, verschwindet jene Bein-Variante).
- Preislogik: wie aus Basispreis plus gewählten Optionen ein Zeilenpreis wird, inklusive Mengenstaffeln und B2B-spezifischer Preisstufen.
- Session- und Warenkorb-Zustand: wie aus einer laufenden Konfiguration eine Warenkorbzeile wird, und was passiert, wenn jemand die Seite verlässt und zurückkommt.
- Rendering: ob die visuelle Ausgabe ein 3D-Viewer, ein 2D-Bildwechsel oder ein Formular mit Live-Preis ist, und welches Markup oder Skript-Tag das auf der Seite braucht.
Eine Bauen-Kaufen-Komponieren-Entscheidung ändert, wer diese vier Stellen kontrolliert, nicht nur, wer den ersten Code schreibt. Deshalb schließen sich die drei Wege auch nicht gegenseitig aus. Ein ausgereiftes Setup mischt meistens: Die Render-Engine wird gekauft, die Regel- und Preisebene bleibt im eigenen Haus.
Weg 1: Bauen
Bauen heißt, euer Team besitzt den Konfigurationszustand, die Preisberechnung und in der Regel auch das Rendering, direkt im eigenen Frontend-Code. Bei einfachen Options-Sets, wenigen unabhängigen Attributen ohne Querabhängigkeiten und ohne 3D, ist das oft der günstigste Weg in der Pflege und per Definition der mit dem geringsten Lock-in: Es gibt keinen Vendor, von dem ihr euch lösen müsstet.
Der Trade-off zeigt sich, wenn die Komplexität wächst. Querabhängige Regeln, diese Option schließt jene aus, diese Kombination löst einen Aufpreis aus, werden zu einer Regel-Engine, die euer Team dauerhaft pflegt. 3D- oder fotorealistisches Rendering ist eine eigene Disziplin; das inhouse zu bauen ist ein echtes Projekt, kein Sprint. Und weil die Logik custom ist, ist auch jede Backend-Anbindung, etwa Preis-Sync oder bestandsabhängige Optionsverfügbarkeit, ebenfalls custom, was eine eigene langfristige Kostenposition ist, auch wenn dabei keine Vendor-Verträge entstehen.
Bauen ist der richtige Standardweg, wenn das Options-Set klein und stabil ist, kein 3D-Rendering nötig ist, und das Team über mehrere Jahre Kapazität hat, eine Regel-Engine zu betreiben.
Weg 2: Kaufen
Kaufen heißt, einen Vendor-Konfigurator zu installieren, am häufigsten Threekit für 3D-Visual-Commerce oder Zakeke für 2D- und Hybrid-Produktanpassung, und ihn Regeln, Preise und Rendering als ein Paket verwalten zu lassen. Beide Anbieter liefern einen einbettbaren Player: Threekits Player wird per Skript geladen und stellt über `player.getConfigurator()` eine Configurator-API bereit, Zakeke stellt eine Configurator-UI-API sowie eine Server-zu-Server-Cart-API für die Checkout-Übergabe bereit.
Kaufen ist schnell. Ein funktionierender 3D- oder 2D-Konfigurator kann in Wochen statt Monaten live sein, und der Vendor übernimmt die Pflege der Render-Engine, die tatsächlich schwer gut zu bauen ist. Der Trade-off ist, dass die Regel- und Preiskonfiguration meist im Authoring-Tool des Vendors lebt, nicht in eurer Codebase. Das ist unproblematisch, solange der Vendor der richtige bleibt. Wachst ihr heraus, wechselt ihr das Backend, oder braucht ihr den Konfigurator anders eingebettet als der Standard-Player es erlaubt, muss die Regel- und Preiskonfiguration meist auf der neuen Seite neu gebaut werden, weil sie nie in einem System ausgedrückt war, das ihr selbst kontrolliert.
Kaufen ist der richtige Standardweg, wenn 3D- oder fotorealistisches Rendering Pflicht ist, Time-to-Market wichtiger ist als langfristige Portabilität, und der Options-Katalog sich so oft ändert, dass ein nicht-technisches Team ihn im Authoring-UI des Vendors pflegen muss.
Weg 3: Komponieren
Komponieren heißt, die API eines Vendors zu nutzen statt seines Standard-Players, und den Konfigurator innerhalb der eigenen Frontend-Ebene zu rendern. Beide, Threekit und Zakeke, unterstützen das: Threekit liefert neben dem Player ein REST-API-SDK und ein composable Configurator-SDK, und Zakekes Dokumentation beschreibt API-Integration für Plattformen außerhalb der unterstützten Liste, direkt über Cart-API und Product-Catalog-API. Der Vendor besitzt weiterhin die Regel-Autorenschaft und bei Threekit auch die Render-Engine selbst. Was sich ändert, ist, wo die UI lebt und wie das Ergebnis in euren Warenkorb kommt.
Der praktische Unterschied zu Kaufen: Statt dass ein Skript-Tag oder iFrame einen fixen Player in die Seite hängt, ruft euer Frontend die API auf, rendert Options-UI und Preis in euren eigenen Komponenten, und übergibt dem Vendor nur die render-lastigen Teile, in denen er tatsächlich gut ist, den 3D-Viewer oder die fotorealistische Vorschau. Warenkorb und Checkout bleiben vollständig im normalen Flow eurer Storefront, statt vom Embed-Verhalten des Vendors abzuhängen. Wechselt ihr später das Backend, ist der Konfigurator-API-Call eine Integration unter mehreren in eurer Orchestrierungsebene, keine seitenweite Abhängigkeit, die in ein bestimmtes Theme eingebacken ist.
Komponieren kostet vorab mehr als Kaufen, ungefähr den Unterschied zwischen Widget-Einbau und API-Integration, hält aber die Teile der Konfigurator-Erfahrung, die eure Kern-Flows berühren, Warenkorb, Preisanzeige, Checkout-Übergabe, in eurer eigenen Architektur statt im Markup eines Vendors.
Ein Entscheidungsrahmen
Keiner der drei Wege ist universell richtig. Was die Entscheidung tatsächlich lenken sollte:
- Options-Komplexität. Spricht für Bauen: Niedrig, wenig Abhängigkeiten. Spricht für Kaufen: Hoch, braucht Authoring-UI für Nicht-Devs. Spricht für Komponieren: Hoch, aber Engineering besitzt die Integration.
- Rendering-Bedarf. Spricht für Bauen: Nur Text- oder Bildwechsel. Spricht für Kaufen: 3D oder fotorealistisch nötig. Spricht für Komponieren: 3D oder fotorealistisch nötig.
- Team-Kapazität. Spricht für Bauen: Engineering betreibt eine Regel-Engine. Spricht für Kaufen: Marketing oder Produkt pflegt Optionen. Spricht für Komponieren: Engineering integriert, Business pflegt Regeln.
- Backend-Stabilität. Spricht für Bauen: Backend-Wechsel unwahrscheinlich. Spricht für Kaufen: Backend stabil, Tempo zählt am meisten. Spricht für Komponieren: Backend-Wechsel in 12 bis 24 Monaten plausibel.
- Checkout-Hoheit. Spricht für Bauen: Volle Kontrolle nötig. Spricht für Kaufen: Vendor-Cart-Übergabe akzeptabel. Spricht für Komponieren: Warenkorb und Checkout bleiben in eurer Storefront.
Die Zeile, die für diesen Beitrag am meisten zählt, ist die Backend-Stabilität. Ist ein Backend-Wechsel plausibel, auch wenn er noch nicht geplant ist, ist Komponieren der Weg, der die Vendor-Beziehung behält, ohne sie zur seitenweiten Abhängigkeit zu machen.
Wie Komponieren in einer composable Frontend-Ebene aussieht
Hier greift die Pillar-3-Perspektive: Eine Composable Digital Experience Platform behandelt den Konfigurator-Vendor genauso wie ein Commerce-Backend, als System, das über einen API-Vertrag angebunden ist, nicht über eingebettetes Markup. Laioutrs Ebene Composability & Orchestration ist der Ort, an dem die API-Calls eines Konfigurators neben Produkt-, Preis- und Bestandsdaten-Calls liegen, sodass ein Wechsel des Render-Vendors oder des Backends einen Integrationspunkt betrifft, kein Seiten-Template.
Für B2B-Storefronts speziell, wo Made-to-Order-Produkte und Preisstaffeln üblich sind, deckt das B2B Growth Kit die umliegenden Muster ab, Angebotsanfragen und Staffelpreis-Anzeige, in die ein komponierter Konfigurator eingebunden werden muss. Und läuft die betroffene Storefront auf Magento, ist Headless Frontend for Magento 2 der Einstiegspunkt dafür, wie derselbe GraphQL-first-Ansatz auf dieses Backend zutrifft, mit den konfiguratorspezifischen Integrationswegen aus dem oben verlinkten Companion-Beitrag.
Komponierte Konfiguratoren halten außerdem die Abläufe aus Solutions: Configurators & Checkout Flows durchgängig intakt, weil die Übergabe von Konfiguration zu Warenkorb nie eure eigene Checkout-Implementierung verlässt.
Unsere Einschätzung
Bauen, Kaufen und Komponieren sind keine Reifegrade, sondern drei verschiedene Antworten auf die Frage, wo die Wechselkosten liegen sollen. Bauen legt sie in euer eigenes Pflege-Backlog. Kaufen legt sie in die Vendor-Beziehung, günstig, bis ihr etwas ändern müsst, wofür der Standard-Player des Vendors nicht gebaut war. Komponieren legt die Wechselkosten in einen einzigen, sichtbaren Integrationspunkt, was die Version ist, für die es sich lohnt, mehr zu zahlen, sobald ihr plant, einen Backend-Wechsel oder einen Wechsel des Render-Vendors zu überstehen, ohne die Storefront drumherum neu zu bauen.
Häufig gestellte Fragen
Muss ich von Tag eins an komponieren, oder kann ich mit Kaufen starten und später wechseln? Mit dem Standard-Player eines Vendors zu starten, ist ein vernünftiger Weg, Nachfrage schnell zu validieren. Der spätere Wechsel zu einem komponierten Setup ist realistisch, wenn der Vendor neben seinem Player eine API bereitstellt, was sowohl bei Threekit als auch bei Zakeke der Fall ist. Schwieriger wird es, wenn der erste Build tief im Seiten-Template auf vendor-spezifisches Markup gesetzt hat, statt auf eine isolierte Komponente.
Ist Komponieren immer teurer als Kaufen? Vorab ja. Ihr baut eine Integration statt ein Skript-Tag einzubauen. Über einen mehrjährigen Horizont, der mindestens einen Backend- oder Render-Wechsel einschließt, ist Komponieren oft günstiger, weil der Umbau-Umfang beim Wechsel kleiner ist.
Kann ich mit einer selbst gebauten Regel-Engine komponieren, statt mit einer Vendor-API? Ja. Komponieren beschreibt ein architektonisches Muster, Regeln, Preise und Warenkorb-Übergabe in der eigenen Frontend-Ebene zu halten, keine bestimmte Vendor-Beziehung. Eine eigene Regel-Engine, gerendert in euren eigenen Komponenten, ist der Bauen-Weg, ausgedrückt auf komponierbare Art, und eine gültige Wahl, wenn das Options-Set kein 3D- oder fotorealistisches Rendering braucht.
Nächste Schritte
Wenn ihr für einen neuen Konfigurator einen Weg wählt, oder einen bestehenden überdenkt, der aktuell an ein bestimmtes Theme oder Backend gebunden ist, bucht eine 30-minütige Demo. Wir schauen uns an, wo eure Konfigurationsregeln, Preise und das Rendering aktuell leben, und was ein komponiertes Setup daran ändern würde.
Mehr von der Laioutr-Plattform
Über den Autor: Marcel Thiesies ist Co-Founder von Laioutr und arbeitet mit Commerce-Teams an Frontend-Architektur-Entscheidungen, die einen Vendor- oder Backend-Wechsel überstehen sollen.