In 19 days, commercetools takes Booth #37 at K5 Berlin - 23 to 24 June. The partner lineup is substantial: basecom, MGM Technology Partners, and neteleven are on the floor. A Pizza Rooftop session follows in the evening with fulfilmenttools and KPS. Well-organized presence - and a concrete opportunity for any CTO or architecture lead who arrives prepared.

Prepared means: not going to the booth with abstract roadmap questions, but with three questions that operationally determine whether your frontend strategy still holds up in 36 months. This post delivers exactly that. No commercetools criticism, no hype - just the questions you would ask yourself anyway when you re-evaluate the project a year after launch.

Question 1: What Does commercetools Frontend vs. Custom Build vs. FMP Actually Cost at 36 Months?

The most common decision point in commercetools projects: the backend has been evaluated and approved. Now comes the frontend choice. Three options are on the table.

Option A: commercetools Frontend (formerly Frontastic). The advantage is direct commercetools integration and vendor proximity for support. The open question: how does TCO behave when you launch a second brand in 24 months, open a new locale, or connect a different marketing tool? commercetools Frontend is tightly integrated with the commercetools ecosystem - that is both a strength and a dependency factor. What does a frontend module swap cost in this setup?

Option B: Custom frontend with Next.js or Nuxt. Maximum control, but realistic 36-month TCO includes initial implementation typically €200k to €1M, an ongoing frontend team including on-call and maintenance typically €300k+ annually, plus connector maintenance per commercetools API update. Teams with internal capacity calculate differently than those financing externally.

Option C: Frontend Management Platform (FMP) as an external layer. An FMP like Laioutr's platform sits on top of the commercetools GraphQL API and decouples the frontend from the backend vendor. No Frontastic lock-in, no permanent custom frontend team. The counter-question for the booth: how does commercetools itself distinguish between what an FMP delivers and what commercetools Frontend offers?

The specific question for Booth #37: what is the contractually fixable price trajectory for commercetools Frontend over 36 months when scaling to two brands, two locales, and 10 new integrations?

The answer tells you whether Option A stays a predictable budget line or whether TCO escalates past a certain scale threshold. A structured comparison of the three options is in our commercetools frontend alternatives post.

Question 2: How Agent-Aware Is the Current Storefront Pattern?

This is the question rarely asked at booths in 2026 - which is exactly why it is the most relevant for a K5 conversation with real depth.

Agentic Commerce is no longer a market trend that becomes relevant in 18 months. AI buyers generate measurable traffic on storefronts today. When an autonomous agent runs a product research flow or a purchasing process, it places structurally different demands on the storefront than a human shopper: stable API contracts, machine-readable data structures, Schema.org markups with full Product and Offer coverage, deterministically consumable GraphQL endpoints.

The question for the booth has two parts.

First: how stable are the commercetools GraphQL contracts across API versions? An agent consuming product and pricing data needs an endpoint that does not change structurally with every release. What is commercetools' current versioning policy for the Storefront API?

Second: what does commercetools Frontend deliver as machine-readable output? Is storefront rendering optimized for structured data - JSON-LD, Schema.org fields in full coverage - or is that a customer task in the frontend implementation?

When you combine a composable backend like commercetools with an agent-ready frontend, the result is an architecture pattern built for the next generation of shoppers. When storefront rendering does not include the agent-aware layer, that becomes a custom build project. The question at the booth: who at commercetools is responsible for the agent-ready storefront layer - the vendor, the partner, or the customer?

This topic is central to Pillar 4 in our content strategy. More on the state of composable commerce and agent-aware architecture patterns is in our State of Composable Commerce 2026 post.

Question 3: What Happens to the Frontend When a Backend Module Is Swapped?

This is the reality check for the composable promise. commercetools positions the ability to swap individual backend capabilities: OMS, PIM, pricing engine, promotion logic. The theory is correct. The question is whether that also holds for the frontend.

A concrete scenario: you have commercetools in the backend and want to replace the promotion engine with a third-party provider - for example, because the native commercetools discount logic hits its limits with complex B2B pricing rules. What happens to the frontend at that point?

With a custom frontend on direct API binding: the frontend team needs to connect the new promotion engine, update existing components, test, and deploy. Timeline depends on integration depth.

With commercetools Frontend: how does the frontend tooling behave when a backend component is replaced by a non-commercetools provider? Is the frontend calibrated to exactly that backend combination, or does it abstract the module boundaries?

With an FMP using a Unified Data Layer: the orchestration layer normalises product, inventory, and pricing data from multiple sources into a unified frontend schema. A backend module swap means, in principle: new connector configuration in the data layer, no frontend rewrite. That is the decoupling promise composable commerce makes - delivered at the frontend layer.

The question for Booth #37: is there a documented case where a commercetools customer swapped a backend module without rewriting the frontend - and what was the concrete effort in the frontend layer?

The answer shows whether composable architecture at commercetools is also lived on the frontend side, or whether the composable promise ends at the backend.

What These Three Questions Accomplish at the Booth

You do not get a sales presentation back. You get information you need for a well-grounded architecture decision.

36-month TCO is not abstract - it has three drivers: initial implementation, ongoing maintenance, and scaling costs. All three vary significantly by frontend model.

Agent-aware architecture is not a nice-to-have in 2026. Anyone planning a storefront redesign in the next 12 months and not building in the agent-ready layer is building twice.

Backend module swap stability is the reality check of the composable promise. If the frontend needs to be rebuilt with every backend change, composable commerce in the backend is half an answer.

All three questions connect: they describe the frontend layer as an independent architecture decision that should be made and evaluated separately from the backend vendor.

If you want a structured frontend evaluation for your commercetools setup after K5 - how the three options (Frontastic, custom build, FMP) perform against your specific scaling scenarios - the starting point is our Headless Frontend for commercetools page. It documents how Laioutr as a Frontend Management Platform connects to commercetools GraphQL and what that means concretely for TCO, time-to-market, and backend independence.

basecom, MGM, and neteleven know the implementation reality from their project work. The questions above work equally well in conversations with the partners as at the commercetools booth itself.

K5, 23 to 24 June, Booth #37. 19 days out.

Related Laioutr resources

Explore how the Laioutr frontend layer applies here:

• Headless Frontend for commercetools
• Composable Headless Frontend
• Agentic Frontend Management Platform