commercetools Frontend Pricing & TCO: What the Frontend Really Costs in a Composable Package

Most commercetools pricing conversations stop at the API. Teams model the commerce backend license, the request volume, the integration budget, and then treat the storefront as a line item that engineering will handle. The result is a Total Cost of Ownership (TCO) figure that looks complete on a slide but misses the layer customers actually touch. commercetools is a headless commerce backend, which means the frontend is not included. Someone has to build, host, maintain, and operate it, and that work runs for the entire life of the storefront, not just the launch quarter. This is a factual breakdown of where frontend cost comes from in a commercetools stack, without invented numbers, so you can size the drivers for your own case.

What commercetools includes, and what it does not, on the frontend

commercetools ships APIs, not a storefront. You get the Composable Commerce backend (product, cart, order, and customer data through GraphQL and REST), the Merchant Center for backend administration, and, depending on your package, tools like Frontend (the former Frontastic) as an optional layer. What you do not get out of the box is a running, branded, SEO-ready storefront with a page editor your marketing team can use without a developer.

That gap is by design. Composable Commerce deliberately unbundles the backend from the presentation layer so you can choose your own frontend approach. The trade-off is that the presentation layer becomes your responsibility. Whether you adopt commercetools Frontend, a separate frontend framework, or a Frontend Management Platform, the storefront is a distinct cost center with its own build, hosting, and maintenance profile. Reading commercetools backend pricing as the full cost of going live is the most common budgeting error in a composable project.

Build versus buy for the storefront

Once the backend is set, the first real decision is build versus buy for the frontend itself. Both are valid, and both carry cost, just in different shapes.

The build path

A custom storefront, typically on a framework like Next.js, Nuxt, or Remix, gives you full control. Your team owns the components, the rendering strategy, and the integration wiring to commercetools and to every best-of-breed service (search, payments, subscriptions). The cost here is front-loaded and ongoing: a dedicated frontend team to reach launch, then a standing capacity to keep it current as the backend, the browsers, and the framework all keep moving.

The buy path

Buying means adopting a frontend product, either commercetools Frontend or a composable, headless frontend platform, that provides the storefront shell, an editing surface, and pre-built integration patterns. You trade some low-level control for a shorter path to launch and a smaller standing engineering commitment. The cost moves from salaries toward a platform fee plus configuration effort.

The honest framing is not "build is expensive, buy is cheap." It is that build converts cost into headcount and calendar time, while buy converts cost into a predictable fee and faster iteration. Which is cheaper over three years depends almost entirely on the hidden costs below.

The hidden costs of a self-built frontend

When teams underestimate frontend TCO, it is usually because these four drivers are missing from the model. None of them appear in a backend license.

Hosting and delivery

A storefront needs rendering infrastructure, a CDN, edge or server-side rendering for SEO and performance, image optimization, and caching. These are recurring costs that scale with traffic and with the number of markets and locales you serve. Peak events (sales, campaigns) drive the sizing, so you pay for headroom you use a few times a year.

Maintenance and upgrades

A frontend is never done. Framework major versions, dependency security patches, browser changes, accessibility requirements, and commercetools API updates all require ongoing engineering attention. This maintenance load is easy to omit from a launch budget and is often the single largest multi-year cost, because it never stops and it competes directly with new feature work.

Editor and authoring tooling

If marketing cannot change a landing page, a hero, or a campaign block without a developer, every content change becomes a ticket. The cost then shows up twice: as developer time spent on content work, and as slower time to market for campaigns. A capable visual editing and content management layer is not a nice-to-have in TCO terms, it is what keeps routine changes off the engineering backlog.

Developer time and opportunity cost

The most under-counted driver is where senior frontend engineers spend their week. Time spent re-plumbing a header, wiring a new payment provider into the checkout, or debugging a rendering regression is time not spent on differentiating experience work. In a composable stack, the promise is best-of-breed everywhere, but every best-of-breed service still has to be integrated and rendered, and that integration surface lives in the frontend.

How a Frontend Management Platform changes the TCO math

A Frontend Management Platform (FMP) sits between the commercetools backend and the storefront and takes ownership of exactly the drivers above. It does not replace commercetools; it renders it. The point is not that an FMP is free, it carries its own fee, but that it consolidates several separate cost lines into one and removes the standing maintenance burden from your team.

Concretely, an FMP changes the math in four places. Hosting, rendering, and delivery become part of the platform rather than infrastructure you size and operate yourself. Framework and dependency upgrades happen at the platform level, so your team is not spending sprints on maintenance that produces no new customer value. Editing moves to a visual surface, so content and campaign changes leave the engineering backlog. And integration to best-of-breed services runs through a unified data layer, so connecting search, payments, or subscriptions is configuration rather than a bespoke build each time. This is the model behind Frontend as a Service: the frontend layer becomes an operated service with a predictable cost, instead of a project your team funds and maintains indefinitely.

The result is not automatically cheaper in year one. A well-staffed team building a focused storefront can launch competitively either way. The difference compounds over years two and three, where the self-built path keeps paying for maintenance, hosting headroom, and developer time on content, while the FMP path holds those as a flat fee and frees the same engineers for revenue work.

Self-built frontend vs. FMP-managed frontend: the TCO drivers

• TCO driver | Self-built frontend | FMP-managed frontend
• Initial build | Dedicated frontend team to launch | Configuration on an existing shell
• Hosting and delivery | Sized, paid, and operated in-house | Part of the platform fee
• Framework and security upgrades | Ongoing team responsibility | Handled at the platform level
• Editor tooling | Built or licensed separately | Included visual editing surface
• Best-of-breed integration | Bespoke build per service | Configuration via a unified data layer
• Cost shape | Headcount plus infrastructure | Predictable recurring fee
• Content change speed | Developer ticket | Marketing self-serve

FAQ

Does the commercetools license include a storefront? No. commercetools is a headless commerce backend. It provides APIs, the Merchant Center, and optional frontend tooling, but a running, branded storefront is a separate build-or-buy decision with its own cost profile.

What is the biggest hidden cost in a commercetools frontend? Usually ongoing maintenance: framework upgrades, security patches, and API changes that never stop and that compete with new feature work. Hosting headroom for peak traffic and developer time spent on content changes are close behind.

Is building a custom frontend always more expensive than buying? Not in year one. A focused team can launch competitively. The gap opens over multiple years, where the self-built path keeps paying for maintenance, hosting, and developer time on routine changes.

How does a Frontend Management Platform reduce TCO? It consolidates hosting, rendering, upgrades, editor tooling, and integration into one operated layer with a predictable fee, and removes the standing maintenance burden from your team, so engineers spend time on differentiating work instead.

Do we have to leave commercetools to use an FMP? No. An FMP renders the commercetools backend through its APIs. The backend keeps running as your source of commerce truth; the FMP owns the presentation and delivery layer on top of it.

More from the Laioutr Platform

• Composable Headless Frontend: how the frontend layer connects to a commercetools backend without a custom build.
• Frontend as a Service: the operated-frontend model that turns build-and-maintain into a predictable fee.
• Agentic Frontend Management Platform: how AI agents take over routine frontend changes that would otherwise cost developer time.
• Composable Digital Experience Platform: where visual editing and content management sit in a composable stack.

Next step

Want to size the frontend layer of your commercetools TCO with real drivers instead of a placeholder line item? Talk to the Laioutr team and we will walk through where your storefront cost actually sits and what an operated frontend would change.