The “all-in-one” model has established itself as obvious in the recent history of e-commerce. From Shopify to Salesforce Commerce Cloud, via Wix or Prestashop, integrated platforms have long been perceived as the rational response to the needs of traders: simplicity of implementation, scalability promise, native integration of marketing, CRM or logistics tools. But at the time of the composable, the reinforced open source, and the verticalization of business needs, this centralized dependence raises questions.
An efficiency that has its limits
The central argument of the integrated platforms is based on fluidity: a coherent, controlled environment, where all technical components communicate without friction. This approach is attractive for small structures or brands in the acceleration phase. It allows a quick time-to-market, limits technical arbitrations, and offers relative budgetary predictability.
But this promise comes up against an operational reality: the needs of e-merchants are complex as they grow. Omnical logics, hyperpersonalization requirements, internationalization or integration of bricks IA require flexibility that monolithic architectures do not always allow.
The return of composable architectures
Faced with these limits, a new technical paradigm emerges: composable commerce (composable trade). In reverse of closed platforms, it is based on a modular logic: each component (CMS, search engine, checkout, ERP, etc.) can be replaced, assembled, interopered.
Solutions like Layer trade,, Medusa,, Storefront view or Dirty embody this trend. Based on APIs, often open source, they allow e-merchants to regain control over their infrastructure. The key: advanced personalization, independence from closed ecosystems, and better adaptation to local or sectoral specificities.
But this approach has a cost: it requires higher technical maturity, rigorous project management, and a constant effort of maintenance and integration. This model therefore remains, for the moment, the prerogative of intermediate actors in advances, with dedicated tech resources.
An issue of technological sovereignty
Beyond the only logic produced alone, dependence on a single platform also questions the sovereignty of data, portability of services, and resilience in the face of service breaks or changes in tariff policy.
Many DTC brands have found themselves constrained by the evolution of economic models of the platforms they used (increase in commissions, functional restrictions, client data partitioning). Conversely, the Headless or Open Source models make it possible to limit this lock-in by guaranteeing reversibility.
In a context of increased regulation (GDPR, DMA, European Marketplaces directives), this technical independence becomes a strategic argument.
Towards a hybridization of models
The debate is not limited to a binary confrontation between integrated platform and composable architecture. A strong trend is essential: hybridization.
Many brands adopt an integrated front-end platform, while migrating certain back-end components to specialized tools (CDP, search engine, logistics orchestration). Likewise, some open source actors integrate SaaS bricks to accelerate adoption (managed accommodation, low-code plug-ins, IA native support).
This hybridization responds to a logic of compromise: benefit from the speed of execution of the Saas while keeping control of critical components.
Conclusion: Choosing is structuring
Behind the question of dependence on a unique platform hides a deeper problem: the capacity of a company to structure its technical stack according to its real issues, its internal culture and its long -term vision.
The choice of an e-commerce environment can no longer be dictated only by the ease of implementation. He must reflect a clear product strategy, an architecture designed to evolve, and technical governance capable of assuming it.
In this sense, the answer is not to deny the platforms, but to put them back in their place: that of a tool at the service of a vision, and not of a framework to which the company must adapt.
