Are MACH and composable commerce the same in ecommerce?

If the board asks "MACH or composable?", answer this first: it is not an A/B choice. MACH describes how the platform should be engineered. Composable describes how you assemble business capabilities from SaaS, open source and custom code.

In practice, the CTO, CFO and Head of Ecommerce should compare three things: architecture risk, integration cost and responsibility boundaries between vendors. A slide full of vendor logos does not explain who owns a wrong checkout price, delayed stock update or campaign that overloads search.

For GMI Software, the better question is not "are we MACH?", but "which commerce capabilities must be independent, which should stay inside MedusaJS v2 and which are worth buying as SaaS because the return is measurable?".

The MACH Alliance popularised the acronym Microservices, API-first, Cloud-native and Headless. In ecommerce, it means checkout, catalogue, pricing, promotions, customer account and storefront are not one inseparable block released once per quarter.

Microservices do not mean "one hundred tiny repositories". They mean domain boundaries that can evolve and scale independently: pricing, inventory, cart, promotions or OMS. API-first means integrations are not an afterthought. Cloud-native means automation, containers, scaling, monitoring and repeatability. Headless means the experience layer is separated from the commerce core.

The key point: MACH can be verified. Ask a vendor for API contracts, versioning strategy, integration logs, rollback plan, order data model and proof that a Next.js storefront and React Native app can use the same source of truth without duplicated business logic.

Composable commerce answers a different question: "which capabilities make up the selling experience?". You can choose a separate commerce core, CMS, search, PIM, payments, OMS, personalisation engine, CDP and mobile app.

That sounds attractive because each component can be best in class. The problem appears when nobody designs the shared data and operating model. Five excellent SaaS tools can create a weak system if price, stock, customer and order mean something different in every tool.

Composable without architecture is just a distributed monolith with more invoices. A strong composable plan has clear systems of record, measured integration SLAs, end-to-end observability, ownership of retries/dead-letter queues and rules for when a new vendor actually adds value.

Choose MACH when the problem is change speed, selective domain scaling, mobile/API reuse, ERP/PIM/WMS integrations and freedom from one monolith. Choose composable when a specific capability matters strategically: search drives conversion, PIM protects catalogue quality, OMS lowers fulfilment cost or CMS gives marketing autonomy.

Choose both when the business runs multi-channel commerce, a mobile app, complex B2B pricing, multiple markets or a roadmap where replacing one component creates real option value. This is often the best fit for MedusaJS v2 as the commerce core with selected services around it.

Choose neither as a large transformation programme if you have 50 SKUs, one market, simple checkout and no integrations. SaaS or a simpler headless stack may return value faster, and MACH can return when sales operations actually become constrained.

Every new API boundary needs schema contracts, versioning, regression tests, retries, idempotency, monitoring, alerts and incident ownership. That is the integration tax. It is not always bad, but it must be counted before another tool enters the stack.

In B2B projects, the first ERP/PIM integration with headless commerce can take more attention than the storefront itself. The edge cases include net/gross prices, currencies, contract discounts, credit limits, partial shipments, returns, invoices, stock across warehouses and sync latency.

During DDT we map that cost before development: which data is synchronous, which is asynchronous, which failures block checkout, which go to queues, who owns the operational dashboard and how the failure cost is measured in team hours and lost orders.

MedusaJS v2 is an open-source commerce framework built around modules, workflows and APIs. Medusa documentation defines a module as a package of functionality related to a single domain or integration, which maps well to MACH thinking: commerce domains are separated and evolved in a controlled way.

In a practical GMI Software stack, MedusaJS v2 often becomes the commerce core: catalogue, cart, order, promotions, checkout, extensions and APIs. Next.js serves the storefront, React Native powers the mobile app, NestJS handles custom policy layers, while PostgreSQL, Redis and queues support persistence and asynchronous flows.

Composable services sit around the core when the business case is strong: Algolia or another search engine for large catalogues, PIM for product data quality, CMS for marketing teams, OMS for multi-warehouse fulfilment, CDP/personalisation for retention. Medusa does not replace composable strategy; it gives it a stable centre.

The first mistake is asking for the number of integrations without asking who owns them. "ERP integration" sounds like one scope item, but inside it live price lists, stock, orders, invoices, limits, returns, statuses and manual corrections. Each area needs a failure scenario.

The second mistake is demanding "MACH" without domain boundaries. A vendor may show microservices, but if price, promotion and checkout changes still require one deployment and one team, the business remains operationally monolithic.

The third mistake is buying composable "just in case". If marketing has no CMS operating process and the catalogue has poor data discipline, another vendor increases chaos. Clean domains first, choose tools second.

The CFO should model TCO in four lines: SaaS licences, implementation cost, operation/integration cost and future switching cost. Composable can be cheaper when a bought capability replaces heavy custom development. It becomes more expensive when every vendor adds subscription, consulting and another point of failure.

The CTO should evaluate five questions: are domains separated well, are APIs versioned, are events idempotent, does the team have observability, and do source code plus data remain under client control? Without that, "modularity" is only a sales promise.

The shared decision is this: choose the smallest number of independent components that removes real business constraints. For one client, that is MedusaJS v2 plus Next.js and ERP. For another, Medusa, PIM, search, OMS and a React Native app. For a third, it is not MACH yet.

We start with DDT: Discovery, Design & Technology. We do not sell a list of buzzwords; we map the buying process, integrations, data, operational roles, mobile, analytics, security and maintenance risk. Only then do we choose architecture and pricing model.

For commerce projects we usually design one product line: Next.js storefront, React Native as the mobile channel, MedusaJS v2 as commerce core, NestJS for custom rules, and ERP/PIM/WMS integrations with monitoring. After DDT we can propose fixed price because risks are named instead of hidden in the backlog.

This is strongest for companies that do not want to be trapped by one SaaS platform but also do not want to fund an academic microservices lab. The goal is ownership, predictable TCO and a roadmap the business team can understand.

MACH Alliance: https://machalliance.org

MACH Alliance overview and history: https://en.wikipedia.org/wiki/MACH_Alliance

Medusa modules documentation: https://docs.medusajs.com/learn/fundamentals/modules

MedusaJS development at GMI Software: https://gmi.software/services/medusajs-development

Headless commerce with Medusa: https://gmi.software/technologies/medusajs

MACH architecture stakeholder guide: https://gmi.software/blog/mach-architecture-stakeholder-guide

When not to adopt MACH ecommerce: https://gmi.software/blog/when-not-to-adopt-mach-ecommerce

Composable commerce and OMS: https://gmi.software/blog/composable-commerce-oms-fulfilment