Composable commerce to open up new markets without rebuilding

Expanding into France, Germany, or Spain shouldn't force a brand to rebuild its ecommerce business every time.

However, many companies discover just the opposite when trying to take their business international: The catalogue needs a different structure, prices depend on local rules and regulations, product listings arrive late, the content doesn't respond to the country's search intent, and every change requires the coordination of technology, marketing, and operations as if it were the first launch.

A lack of commercial ambition is not usually the problem. The problem arises when the platform, data, and content flows have grown as isolated entities. Therefore, opening up to a new market ceases to be a business decision and becomes a long, expensive, and difficult-to-replicate technological project.

Composable commerce proposes a more flexible response: connect specialised capabilities so that they can evolve independently and work as a system.

Its value lies not in accumulating tools, but in creating an architecture where the catalogue, commerce, content, automation, SEO and data share clear rules. This means that for the next market you can take advantage of what has already been built and concentrate your efforts on what really needs to be localised.

Why does composable commerce accelerate access to new markets?

International expansion multiplies variations. The same product may require different prices, currencies, availability, delivery times, sales pitches, legal information, and SEO strategies depending on the country.

Campaigns, payment methods, taxes, returns, and service expectations also change. If all that logic is embedded in a rigid platform, any adjustment affects too many constituent parts and requires technical intervention.

In traditional architecture, the sequence is usually repeated: Spain is one project, France another, and Germany a third. Pages are copied, parallel spreadsheets are created, files are sent between teams, and inconsistencies are corrected when the store should already be ready.

The cost is not limited to development. It also appears in the hours spent coordinating, catalogue errors, loss of organic visibility, and delays in campaigns that depended on a launch date.

The composable approach changes the unit of work. There is a shared core of product, orders, and customers, and market-specific rules apply to it. The key is in separating the common from the local. Master data is reused, while currency, price, assortment, language, content, metadata or commercial conditions are configured according to each destination.

As a result, the question ceases to be "How do we clone the store?" and becomes "What capabilities should we activate or adapt?".

The upshot is clear: Each new market can become a governed configuration, not a complete reconstruction. This repeatability reduces launch time and, above all, allows you to learn from one country to improve for the next.

What is composable commerce and how does it change expansion?

Composable commerce is an architectural approach that organises an ecommerce business through modular capabilities connected via interfaces. The catalogue can reside in a PIM, the financial and stock information in an ERP, the transaction in a trading platform, the content in a CMS, and the customer relationship in a CRM. Each piece has a defined function and can evolve without requiring the entire ecosystem to change at the same time.

Do not confuse it with a headless solution. A headless solution separates the presentation layer from the commerce logic, making it easier to create distinct experiences on the same engine. Composable goes one step further: It also allows you to modulate capabilities such as search, promotions, content, payments, and personalisation.

MACH, for its part, describes a set of technical principles, microservices, API-first, cloud-native and headless, which can be used to implement a composable architecture. MACH Alliance presents these principles as a basis for building open, connected business systems capable of evolving component by component. Not every project needs to adopt every principle at once.

This distinction matters because a company can benefit from the composition without embarking on a complete migration.

In practice, this involves identifying the bottleneck preventing growth, decoupling that capacity, and connecting it to the existing system.

Sometimes the first step is to centralise the catalogue; other times you automate the flow of international content or create a layer that synchronises CMS, ecommerce and marketing tools.

The right architecture is not simply the one that incorporates the most components. It's the one that reduces dependencies, defines responsibilities, and allows one part to change without destabilising the others. The decision must be business-oriented: time to launch, data quality, team autonomy, ease of maintenance, and the ability to adapt the experience to each market.

From launching projects to activating markets

The true promise of a connected architecture comes when the complete flow is observed. The ERP and PIM provide reliable data on product, inventory, price, and attributes.

The trading platform manages transactions. An integration and automation layer, such as MIA within the ATLS Global ecosystem, distributes and transforms information. The CMS organises content by language or region. The CRM and analytics provide signals about demand, behaviour, and performance.

When these layers share identifiers, rules, and states, a change no longer depends on manual strings. A material or availability update can be propagated to the relevant channel. A new market can inherit the core of the catalogue and receive only the approved variants. Local teams work on fields and decisions that correspond to them, without duplicating the entire structure.

To achieve this, you need to define an operating model, not just connect APIs. The master source of each piece of data, who approves an adaptation, what happens when a field is incomplete, and how a local exception is logged must all be clear. It is also advisable to design visible states, for example, pending translation, reviewed by market, validated for SEO and ready to publish.

This means that scalability doesn't depend exclusively on technology. It depends on the system translating the way the company actually works. An integration lacking in governance can cause errors to spread faster. A well-designed architecture, on the other hand, reduces repetitive work and waits for human judgement for decisions with commercial impact.

How to connect an international ecommerce business

Before choosing a technological solution for Shopify, it is advisable to map the flow of information. Where does a product originate? What system determines its availability? Who creates the base content? How are local keywords assigned? What conditions must be met for it to be published? What data is returned after launch? These questions reveal duplications and dependencies that a software list does not show.

A robust international flow typically relies on five capabilities:

• Reliable master data. The ERP or PIM retains identifiers, attributes, variants, prices, and availability with a reusable structure.
• Configurable commerce engine. The platform applies market-specific rules for assortment, currency, taxes, payment, promotions, and logistics.
• Localised content. The CMS or editorial layer links each piece to its product, market, language, search intent, and approval status.
• Observable integration. Plugins log errors, retries, changes, and responsible parties to prevent opaque synchronisations.
• Continuous learning. CRM, analytics and SEO data inform decisions about the catalogue, content, and campaigns.

Not all companies need their own PIM, headless CMS, or microservices from day one. The decision depends on the catalogue volume, the number of markets, the frequency of changes, and the complexity of the rules.

ATLS adds value precisely in that intermediate reading: Connect what already works, resolve priority friction, and prepare the system to incorporate new capabilities when the business needs them.

The content and SEO are part of the architecture

Publishing a catalogue in another language is not the same as building demand. The same category can respond to different searches depending on the country, and a correct translation can be irrelevant if it doesn't use the same vocabulary as local users. Therefore, international SEO must enter the workflow before publishing, not added as a last-minute review.

The process starts with market research and keywords. Next, define which pages should exist, what purpose each one covers, and how categories, products, guides, and editorial content are related.

This semantic architecture should be reflected in titles, meta descriptions, headings, text, internal links, and structured data. It also requires stable URLs, consistent regional versions, correct hreflang tags, canonicals, and updated sitemaps.

Google Search Central recommends using different URLs for each language and indicating regional variations with hreflang tags. Shopify, for example, allows you to assign domains, subdomains or subfolders and languages ​​to specific markets, and automates some of the technical elements when the configuration is correct. But the platform does not decide the local value proposition nor does it guarantee that a translated listing corresponds to a real search.

The key is to treat the content as structured data. Each asset needs to be related to an SKU or category, target market, language, keyword, template, responsible party, date, and quality control status. This makes it possible to automate distribution without losing traceability. SEO ceases to be a separate document and becomes a condition of publication.

What to automate and what to keep reviewing

AI can accelerate high-volume tasks, such as generating first drafts, adapting formats, classifying attributes, detecting empty fields, and proposing metadata. It can also help compare versions and point out inconsistencies between the PIM, the CMS, and the store. In extensive catalogues, this support reduces an operational burden that would grow linearly with each language.

However, automation doesn't imply not being in control of what you publish. Product claims, terms and conditions, brand messaging, and pages with the greatest organic potential need human review. Ambiguous terms, cultural sensitivities, and any content where an error could affect trust or conversion should also be reviewed.

A practical model distinguishes three levels. Repetitive and verifiable tasks are automated. Medium-risk parts undergo sampling and validation rules. Strategic or sensitive content receives specialised approval. In practice, this means combining speed with clear quality thresholds, defined responsibilities, and logs that allow you to know what was generated, what was modified, and who approved it.

Case study: Scaling an international catalogue

The case of Flabelus helps to visualise the challenge on a real scale. The scope includes more than 1,500 products and more than 2,200 international keywords. In volumes as large as this, the problem is not limited to translating product listings. It is necessary to relate product, market, search term, metadata, content and publication status without losing coherence.

A manual workflow would require coordinating thousands of decisions across parallel files. With a connected architecture, the master catalogue feeds an automation layer, keywords guide local adaptations, and content goes through controls before reaching the CMS and ecommerce. The team can focus on exceptions, business priorities, and editorial quality.

There is also external evidence of the impact that a more flexible architecture can have. Shopify documents TASCHEN's case, which integrated a headless configuration with PIM and launched its new international store in five languages ​​after five months of development.

The company later reported a 20% year-on-year increase in revenue, 12% more orders, and a 6% increase in average order value. It's not a replicable guarantee, but it does demonstrate how the connection between platform, product, and experience can sustain real expansion.

When do you need a more composable architecture?

There's no need to wait for the platform to fail. There are operational signs that indicate rigidity is already limiting growth:

• Each new country requires processes to be copied and integrations to be rebuilt.
• The catalogue, prices, and content are corrected in several tools at once.
• Marketing depends on development for frequent and predictable changes.
• Local teams create parallel solutions because the central system is not responding.
• The translations are published without keywords, metadata, or quality control.
• Changing a supplier requires too many parts of the ecommerce platform to be modified.
• No one can clearly explain where the correct data is or why a publication failed.

If one or more of these situations are common, the priority shouldn't be to replace the entire platform immediately. It is advisable to audit the workflows, find out where the most time is wasted, and design an evolution based on capabilities. The first project should solve a visible problem and leave a reusable foundation for the next market.

Composable commerce is useful when it turns complexity into controllable options. For ATLS Global, the differentiating factor lies in connecting technology, automation, content and international SEO around a specific goal: ensuring the next market is easier to break into than the previous one. Architecture shouldn't dictate how fast the business can grow.

Frequently asked questions about composable commerce

Sources consulted

• MACH Alliance, “MACH Principles”.
• Google Search Central, “Managing multi-regional and multilingual sites”.
• Shopify Help Center, “Assigning domains and languages ​​to marketplaces”.
• Shopify Spain, TASCHEN's success story.
• Kiwop, “Composable commerce: modular architecture for ecommerce enterprise”.
• Shopify, “Composable Commerce: What Does It Mean?”.

Gerard Lapiedra