There is one decision in almost every commerce replatforming that gets postponed until it is too lat…
OXID Frontend Alternative: FMP vs Custom Build
OXID eShop is a strong DACH B2B platform, but the frontend strategy is a separate question. Anyone looking for an OXID frontend alternative usually has a clear trigger: modernize Flow Theme, reduce custom-build engineering effort, increase marketing velocity.
In this post we show three scenarios in which an FMP is the better choice, and when it should still be Flow Theme or a custom build.
The established options, honestly classified
Flow Theme (default storefront): Shipped with OXID by default, Smarty-based, not headless. Sensible for existing setups that don't want to migrate.
Wave Theme: More modern variant of the default theme, also Smarty-based. Sensible as an intermediate step before headless.
Custom build with OXID GraphQL StoreFront: Maximum control, six- to nine-month build phase. For teams with dedicated frontend engineering.
Laioutr FMP: The strategic middle. Headless advantages without custom-build effort, B2B components out of the box, EU hosting, fastest time to launch.
Scenario 1: modernize Flow Theme without engineering growth
You've been running Flow Theme for years. It works, but feels dated. A modern storefront is wanted, but building a dedicated Next.js team is not in the budget or culture.
With an FMP, you go modern without engineering growth. Themes and components are there, marketing works independently.
Scenario 2: accelerate B2B workflows without engineering sprints
You use OXID EE for B2B: account selection, permission sets, customer-specific catalogs. But every new workflow is a Smarty template edit or a custom-build sprint.
With standard B2B components in an FMP, that becomes configuration instead of engineering. Permission UIs, account selection flows, customer-specific catalog renderings are available from day one.
Scenario 3: reduce custom-build maintenance
You have a custom build with Next.js and OXID GraphQL StoreFront running, but the engineering team is thinned out. Maintenance gets expensive, new features stagnate, marketing waits.
With an FMP, the vendor bundles maintenance, engineering is free for backend strategy.
When custom build is still the better choice
Three constellations:
Maximum pixel-level differentiation. Industrial goods, custom configurators, real-time visualizations that no standard components cover.
Mature engineering teams with Next.js experience. At least three engineers, frontend is a strategic core competence.
Highly specific B2B workflows. Complex approval hierarchies, industry-specific permission logic that no standard components cover.
When Flow Theme is still the better choice
One constellation:
Very small setup without modernization pressure. If Flow runs stably and conversion rate is acceptable, "don't touch it" is a valid strategy.
What you can concretely expect from an FMP migration
From the OXID projects we have supported:
Marketing velocity rises significantly.
Total cost of ownership over 5 years typically lies 30 to 50 percent below custom build.
B2B time to feature drops significantly.
What the transition concretely looks like
We mostly see a controlled two-phase path: First set up a second storefront (new brand, new market) on the FMP. Then migrate the main shop. Detailed migration path in OXID headless migration, step by step.
Conclusion: FMP is the strategic middle
Flow Theme, Wave Theme, custom build, and FMP are all valid options, depending on team setup and modernization pressure. The FMP is the strategic middle: headless advantages without custom-build effort, B2B standard functions out of the box, marketing velocity. Exactly right for DACH mid-market OXID buyers who want to modernize without building a frontend engineering team.