Integrations in Minutes: App Store, Not Engineering TicketTime-to-market is rarely decided in the ar…
Modular Commerce: The Bottleneck Moved to the Frontend
Modular commerce solves the replatforming problem where it started: in the backend. And by doing that, it exposes where the real time-to-market bottleneck actually sits, which is the frontend. If you roll out core commerce in eight weeks and then have a separate interface built for every single module, you have moved the bottleneck, not removed it.
Our take: this is the most important architectural shift of the year, and most roadmaps still do not price it in.
What actually shifted in the market
Since July 2026, commercetools has been selling its offering as modules. Core Commerce with cart, order, checkout, customer and B2B on one side. Product Catalog with product modeling, pricing, inventory and search on the other. Both can be bought individually instead of only as a full platform. The details are in the modular commerce announcement.
Doug McNary, CEO of commercetools, frames the move like this:
"As the pace of commerce innovation accelerates, companies can no longer afford to wait years to modernize. Enterprises want to solve immediate business problems, prove value quickly and evolve over time."
There is nothing to argue with there. It is correct. What matters just as much is who is saying it: a vendor with more than 600 brands on the platform and roughly 120 billion euros in annualized GMV. When the composable incumbent breaks the replatforming project into purchasable pieces, that is not a product detail, it is a market signal. The message to the market is simple: modernization runs incrementally, not as a big bang.
The direction of travel is unambiguous. The only open question is whether the math is complete.
Why the bottleneck moves instead of disappearing
A module ships an API. An API does not ship business value. Value shows up where a customer can see something, understand it and buy it, which is the presentation layer.
That is exactly why the math shifts rather than shrinks. Before, the budget held one large replatforming project with a clear start and a clear end. Now it holds several small backend rollouts, and next to them, usually unquantified, one frontend project per module.
- Backend rollout Classic replatforming: one large project. Modular commerce without a frontend layer: several small, plannable steps.
- Frontend effort Classic replatforming: one-time, but large. Modular commerce without a frontend layer: repeated per module, larger in total.
- Visible customer value Classic replatforming: at the end of the project. Modular commerce without a frontend layer: only after the matching interface ships.
- Risk Classic replatforming: concentrated at go-live. Modular commerce without a frontend layer: distributed, but permanent.
The pattern is not new. We saw it when speed became the primary driver behind composable decisions, which we broke down in our analysis of speed to market as a composable driver. Modular commerce simply makes the pattern far more visible, because the backend side is now neatly sequenced and the frontend side is not.
The line item missing from the module math
Run the numbers for yourself. You buy Product Catalog because your pricing urgently needs to be more flexible. Four weeks later the module is connected. Then someone asks the question that decides everything: where exactly does a customer see the new price, in which markets, under which brand, in which channel, and who builds that?
At that point the clock restarts, only now it runs in the frontend team. Same thing with the next module. In our project conversations we regularly see composable programs that stretch past nine months even though the backend was ready long ago. The reason is almost always the same: frontend, integration and deployment were rebuilt in parallel, each one treated as a special case.
The point is not that backend modularization is wrong. It is right, and it is overdue. The point is that modularity only produces time to market when it exists on both sides of the API. Otherwise you buy speed in the backend and pay it back in the frontend. We walked through what that experience layer has to look like on the commercetools stack in enterprise commerce in days, not months.
What this means for you as a decision maker
Three consequences I would hand to any CEO or commerce lead:
First, measure the right number. Not time to module go-live, but time to the first revenue that actually flows through that module. The gap between those two numbers is your frontend gap.
Second, decouple the frontend layer before you buy the second module. As long as the presentation layer is welded to a single backend, it inherits every backend decision. An independent frontend layer on top of a Composable Digital Experience Platform flips that around: the backend becomes replaceable and the interface stays put.
Third, treat the presentation layer as modular too. If cart, search and pricing arrive as modules, then components, pages and campaigns have to snap together the same way. That is the job of composability and orchestration in the frontend, and the reason we built Laioutr as a Frontend Management Platform rather than another template set.
In practice that means a standard connection to more than 50 backends, including commercetools behind a decoupled frontend, a studio where marketing builds pages instead of waiting for a sprint, and one component library that applies across every brand and market at once. The numbers behind that come from our own projects: 65 percent shorter time-to-launch for new landing pages compared with a classic headless setup, and a median of under 14 days for a founder-guided migration.
None of this is an argument against modular commerce. It is the missing half of the math. Keep both sides modular and you get exactly what McNary describes: fast proof of value instead of multi-year programs. Modularize only the backend half and you get faster backend projects, then wait just as long as you did before.
FAQ
Is modular commerce a replacement for composable commerce? No. It is a purchasing and rollout model inside a composable architecture. You no longer buy the whole platform at once, you buy the capabilities you need first.
Why is a modern backend alone not enough for time to market? Because a module ships an interface, not a user interface. Customers never see the API. Only the presentation layer turns a capability into revenue, and that is precisely where the effort sits that the module math usually leaves out.
Do we have to replace our backend for this? No, quite the opposite. The frontend-first path works best when the backend stays exactly where it is. You decouple the presentation layer, then adopt modules at your own pace without rebuilding the interface a second time.
How quickly can a frontend layer be productive? For a single-brand setup, the median across our guided migrations is under 14 days. Multi-brand and multi-market scenarios take longer, as expected, because brand tokens, locales and permissions have to be planned in.
What is the sensible first step? Take the module that is next on your roadmap and honestly quantify what the matching interface will cost. If that number is larger than the module rollout itself, you have found the business case for an independent frontend layer.
Next steps
If a module roadmap is taking shape on your side, it is worth looking at the other side of the API before the first module goes live. Book a 30-minute demo and we will walk through your roadmap and put a number on the frontend share.
More from the Laioutr platform
About the author: Marcel Thiesies is CEO and co-founder of Laioutr. He works with retailers and brands across the DACH region to pull the frontend layer out of the replatforming project.