Wer die Customer Journey im Automobilgeschäft aufzeichnet, bekommt fast immer dieselbe Folie: Aufmer…
OXID Frontend Alternative: Wann FMP statt Custom Build?
OXID eShop ist eine starke DACH-B2B-Plattform, aber die Frontend-Strategie ist eine eigenständige Frage. Wer eine OXID Frontend Alternative sucht, hat meistens einen klaren Auslöser: Flow Theme modernisieren, Custom-Build-Engineering-Aufwand reduzieren, Marketing-Velocity erhöhen.
In diesem Beitrag zeigen wir drei Szenarien, in denen eine FMP die bessere Wahl ist, und wann es weiterhin Flow Theme oder ein Custom Build sein sollte.
Die etablierten Optionen, ehrlich eingeordnet
Flow Theme (Default-Storefront): Mit OXID standardmäßig mitgeliefert, Smarty-basiert, kein Headless. Sinnvoll für Bestands-Setups, die nicht migrieren wollen.
Wave Theme: Modernere Variante des Default-Themes, ebenfalls Smarty-basiert. Sinnvoll als Zwischenschritt vor Headless.
Custom Build mit OXID GraphQL StoreFront: Maximale Kontrolle, sechs- bis neunmonatige Build-Phase. Für Teams mit dediziertem Frontend-Engineering.
Laioutr FMP: Die strategische Mitte. Headless-Vorteile ohne Custom-Build-Aufwand, B2B-Komponenten out of the box, EU-Hosting, schnellste Time-to-Launch.
Szenario 1: Flow Theme modernisieren ohne Engineering-Wachstum
Sie betreiben Flow Theme seit Jahren. Es funktioniert, aber wirkt veraltet. Eine moderne Storefront ist gewollt, aber ein dediziertes Next.js-Team aufzubauen ist budgetär und kulturell nicht im Plan.
Mit einer FMP gehen Sie modern, ohne Engineering-Wachstum. Themes und Komponenten sind da, Marketing arbeitet eigenständig.
Szenario 2: B2B-Workflows beschleunigen ohne Engineering-Sprints
Sie nutzen OXID-EE für B2B: Account-Selection, Permission-Sets, kundenspezifische Sortimente. Aber jeder neue Workflow ist ein Smarty-Template-Edit oder ein Custom-Build-Sprint.
Mit Standard-B2B-Komponenten in einer FMP wird das Konfiguration statt Engineering. Permission-UIs, Account-Selection-Flows, kundenspezifische Sortiments-Renderings sind ab Tag eins verfügbar.
Szenario 3: Custom-Build-Wartung reduzieren
Sie haben einen Custom Build mit Next.js und OXID GraphQL StoreFront laufen, aber das Engineering-Team ist ausgedünnt. Wartung wird teuer, neue Features stagnieren, Marketing wartet.
Mit einer FMP bündelt der Anbieter die Wartung, Engineering ist frei für Backend-Strategie.
Wann Custom Build weiterhin die bessere Wahl ist
Drei Konstellationen:
Maximale Pixel-Level-Differenzierung. Industriegüter, Custom-Konfiguratoren, Echtzeit-Visualisierungen, die keine Standard-Komponenten abdecken.
Reife Engineering-Teams mit Next.js-Erfahrung. Mindestens drei Engineers, Frontend ist strategische Kernkompetenz.
Hochspezifische B2B-Workflows. Komplexe Approval-Hierarchien, branchenspezifische Permission-Logic, die keine Standard-Komponenten abdecken.
Wann Flow Theme weiterhin die bessere Wahl ist
Eine Konstellation:
Sehr kleines Setup ohne Modernisierungsdruck. Wenn Flow stabil läuft und Conversion-Rate akzeptabel ist, ist „nicht anfassen" eine valide Strategie.
Was Sie konkret von einer FMP-Migration erwarten können
Aus den von uns begleiteten OXID-Projekten:
Marketing-Velocity steigt deutlich.
Total Cost of Ownership über 5 Jahre liegt typischerweise 30 bis 50 Prozent unter Custom Build.
B2B-Time-to-Feature sinkt deutlich.
Wie der Übergang konkret aussieht
Wir sehen meistens einen kontrollierten Zwei-Phasen-Pfad: Erst eine zweite Storefront (neue Brand, neuer Markt) auf der FMP aufsetzen. Dann den Hauptshop migrieren. Detaillierter Migrations-Pfad in OXID Headless Migration, Schritt für Schritt.
Fazit: FMP ist die strategische Mitte
Flow Theme, Wave Theme, Custom Build und FMP sind alle valide Optionen, je nach Team-Setup und Modernisierungsdruck. Die FMP ist die strategische Mitte: Headless-Vorteile ohne Custom-Build-Aufwand, B2B-Standardfunktionen out of the box, Marketing-Velocity. Genau richtig für DACH-Mittelstand-OXID-Käufer, die modernisieren wollen, ohne ein Frontend-Engineering-Team aufzubauen.