commercetools Frontend: When Is the Switch Worth It? (2026)
commercetools delivers an excellent composable commerce backend, that's undisputed in the DACH market. But the frontend stack on the customer-facing side doesn't ship in the box. Every ct project hits the question "which frontend strategy?" sooner or later, and the right answer depends on the growth phase.
If you built your frontend stack 2 or 3 years ago, you're probably seeing symptoms today that point toward a switch. If you're starting fresh on ct, ask the question proactively before the frontend becomes a burden.
This guide helps you make the call cleanly, including the situations where we actively recommend against it.
What does "commercetools frontend" mean?
Unlike Shopify or Shopware, commercetools doesn't ship a default frontend. You pick from three established options: custom build (Next.js or Nuxt), commercetools Frontend (Frontastic) or a Frontend Management Platform like Laioutr. A full overview of the options lives on our Frontend for commercetools hub page.
Five symptoms that point toward a switch
1. Frontend backlog grows faster than your engineering team
You have a custom Next.js stack, built two years ago. Every new feature request runs through the React team, and the backlog grows twice as fast as team capacity. Marketing waits, stakeholders are frustrated, new initiatives slip by quarters.
That's the clearest signal: you need a platform that lets marketing and content teams be productive independent of engineering.
2. Multi-brand or multi-market strategy gets concrete
A second brand joins the ct stack, or you expand into a new market with own layout, language, brand identity. With custom Next.js, that means a second codebase, doubled maintenance, possibly inconsistent components.
A Frontend Management Platform with central component pool and multiple storefronts on one platform scales here structurally differently.
3. Frontastic lock-in becomes a strategic risk
You picked Frontastic when ct acquired the product in 2021. The stack runs, but license costs are tied to ct pricing, and the frontend code lives in the ct ecosystem. A later backend diversification would be a complete rebuild.
If you want backend optionality strategically, the frontend choice shouldn't bind you to a single vendor.
4. EU accessibility compliance becomes an enterprise requirement
Since 2025, the EU Accessibility Act and Germany's BFSG are mandatory for nearly every commercial online shop. With a custom stack that means: audit every component, external accessibility consultancy, five-figure compliance investment. With an FMP that has WCAG 3.0 and BFSG already anchored in the components, you skip the internal audit project.
5. Performance is no longer competitive
Lighthouse scores stagnate at 60 to 70 despite the engineering team running optimization sprints. With a hand-built stack, the performance ceiling is often architectural. Component-based FMPs targeting Lighthouse 100 break that ceiling structurally.
When a switch is not (yet) worth it
Three situations where we actively recommend against:
You're mid-replatforming on ct itself. If the ct backend is being migrated, don't parallelize with a frontend overhaul. One project at a time, otherwise risk doubles.
Your custom stack is younger than 18 months. If you just built and the team is productive, the switch rarely earns its ROI in acceptable time. Wait until real pain points surface.
No architect in-house. An FMP migration without a technical owner rarely ends well. At minimum one architect should actively carry the project, either internally or via a composable partner like valantic.
Three rules of thumb for the decision
- Frontend backlog longer than 6 months? Strong signal to evaluate FMP.
- Lighthouse score below 80 after 3 optimization sprints? Strong signal to question the frontend stack.
- Multi-brand or multi-market roadmap concrete? Strong signal to choose a platform that scales with it.
If two of three apply, the question stops being "if" and becomes "how".
What a frontend switch concretely changes
From the ct projects we've supported, three effects show up within 90 days:
Time-to-market for new landing pages and campaigns drops from weeks to hours, because marketing builds in Studio independently and no longer goes through engineering.
Performance becomes a default. Lighthouse 100 stops being a project goal and becomes a component standard. Direct effect on SEO ranking and conversion rate.
Multi-market scaling becomes a configuration step, not a repository fork.
A pragmatic entry
A complete migration in one step is rarely the right approach. What works: start with a single storefront, for a new brand, a new market or a campaign microsite. The architecture decision gets validated under controlled conditions before the main shop migrates.
The full migration path including 301 redirect strategy and SEO transition is in commercetools Frontend Migration, Step by Step.
Bottom line: frontend strategy is an architecture decision
If you've got more than two hits on the symptom list, take the frontend switch seriously. If you've got zero or one hit, your existing stack is probably fine. The truth lives in the growth path: a stack that holds up today might hit limits in 18 months.
If you're unsure, we'll happily walk through it with you. We'll show Laioutr live against your ct setup and tell you honestly whether a switch makes sense, including when the answer is "not yet".
