When is MACH architecture a bad idea for ecommerce?
Short answer: do not adopt MACH if you do not have a real problem with change velocity, integrations, channel scale, data ownership or the TCO of your current platform. Shopify B2B and BigCommerce show that modern SaaS can cover many B2B needs. MACH starts to make sense only when SaaS constraints block revenue, margin, mobile, ERP/PIM/WMS or product roadmap.
Start with the test: do you have a problem MACH really solves?
MACH makes sense when the current platform blocks measurable business decisions: changes require freezing the whole store, ERP/PIM/WMS integrations are fragile, mobile needs duplicated logic, and SaaS fees or vendor lock-in start affecting margin.
It does not make sense when the company simply needs to launch faster with a small catalogue, standard checkout and standard B2B. Shopify B2B lets teams personalise pricing, currency, products, payment, shipping and content for companies inside Shopify admin. BigCommerce names B2B needs such as pricing, account management, ERP integration, PIM, WMS and CRM. So "we need B2B" is not yet an argument for MACH.
At GMI Software, we advise against MACH when architecture is meant to prove modernity rather than remove a bottleneck. A serious project starts with DDT: where margin leaks, where teams retype data, where the platform blocks mobile or integrations, and what inaction costs.
When SaaS is more rational than MACH
SaaS wins when you have a standard catalogue, standard checkout, few integrations and a need to launch quickly. If the biggest business risk is "will customers buy online at all?", do not fund a platform built for scale that does not exist yet.
SaaS also makes sense when the team lacks DevOps, integration ownership and a maintenance process. Platforms such as Shopify, BigCommerce, Shoper or IdoSell absorb hosting, some security, updates and standard admin workflows. That limits architecture freedom, but reduces operational load.
The honest test: if 80% of requirements fit SaaS defaults and the remaining 20% does not affect margin, retention, mobile or B2B sales, stay on SaaS. Put budget into product data, SEO, analytics, checkout UX and the integrations already hurting today.
When simpler headless is enough
Between SaaS and full MACH sits a useful middle path: a headless storefront on top of an existing commerce backend. You can keep Shopify, BigCommerce or Magento as the core while improving the Next.js frontend, mobile performance, content layer and analytics without splitting everything into microservices.
This fits when the problem is buying experience, SEO, Core Web Vitals, mobile conversion or content velocity, not order-management rules or vendor lock-in. It can be a bridge: faster business impact while cleaning API and data boundaries before a larger migration.
GMI often recommends this when the client needs results this quarter but does not yet have enough evidence for a big platform decision. Headless-light can be a stage, not a permanent compromise.
When MACH is operationally too expensive
MACH moves part of the cost from platform licence into integrations, observability, DevOps, regression testing, vendor management and incident ownership. ITPro describes MACH limitations: difficult migration, more vendor relationships, middleware, compliance, data silos and business disconnect. These are not abstract risks. They are maintenance budget lines.
If the team cannot run CI/CD, logs, tracing, alerts, queues, API versioning and contract tests, MACH can reduce velocity instead of increasing it. Every "independent component" needs an owner, runbook and monitoring.
That is why we assess organisational capability, not only technology. If one person "knows ERP", another "knows the shop" and nobody has time for operational architecture, fix ownership first. Split the platform later.
When MACH still makes sense
MACH makes sense when constraints are concrete and recurring: multiple sales channels, a mobile app sharing the same cart, B2B pricing, ERP/PIM/WMS, marketplace, split checkout, CPQ, multi-warehouse fulfilment, fast campaigns and rising SaaS workaround cost.
Good signals: backlog full of "the platform cannot" tickets, CSV-based integrations, manual price corrections, slow mobile, separate web/app logic, weak data ownership or fees/take rates that start eating margin.
Then MedusaJS v2, Next.js, NestJS, PostgreSQL, Redis and queues can be a better foundation than more SaaS patchwork. But we still start with DDT: domains, risks and TCO first, stack decision second.
Break-even: how to model the decision without magic
Compare 24-36 months, not only implementation cost. On the SaaS side, count subscription, fees/take rates, apps, paid add-ons, API limits, agency work, custom middleware and workaround cost. On the MACH side, count DDT, development, data migration, integrations, testing, hosting, monitoring, maintenance and operations team cost.
Then add the cost of inaction: lost mobile conversion, manual sales work, pricing errors, overselling, delayed campaigns, missing ERP integration or inability to launch marketplace/B2B portal.
If MACH has no clear payback in margin, change speed, reduced manual work or new channels, it is too early. If payback depends on one optimistic assumption, build a smaller proof-of-value stage first.
Can a small IT team run MACH?
Yes, but only with a clear operating model. A small team plus production partner, SLA, runbooks, monitoring and domain ownership can work better than a large team without decisions. The problem starts when one person "does everything" and PTO blocks release or incident response.
Staff augmentation without product ownership is also usually not enough. You get capacity, not responsibility for product outcomes. MACH requires domain decisions: system of record, sync vs async, dead-letter queue ownership.
If you do not have that, do not start with full MACH. Start with DDT, integration map, observability of the current stack and a small module that proves the operating model.
Signals to revisit MACH in 12-18 months
Not now does not mean never. Revisit the topic when integration tickets grow, SaaS workarounds get more expensive, mobile app pressure rises, B2B customers need an order portal, and product/pricing data mature into separate domains.
Collect evidence meanwhile: monthly manual correction hours, pricing-error cost, campaigns delayed by the platform, orders requiring sales contact, and where mobile loses conversion.
If those numbers show recurring cost in 12-18 months, DDT becomes shorter and sharper. You will not sell "MACH" to the board, but a decision to remove measured operational debt.
What should you do instead of MACH today?
Reduce technical debt: clean APIs even inside a monolith, checkout regression tests, monitoring for core paths, product data discipline, stable customer/order IDs, data exports and integration documentation.
Improve the things you will need in MACH anyway: PIM discipline, pricing ownership, analytics, event tracking, mobile performance, runbooks and systems-of-record map. Those investments do not disappear even if you stay on SaaS for another year.
If you are unsure where to start, GMI can run a lighter DDT/audit: current stack assessment, TCO, SaaS constraint list, integration map and a decision to stay, harden, go headless-light or plan MedusaJS v2.
Sources and further reading
Shopify B2B documentation: https://help.shopify.com/en/manual/b2b
BigCommerce B2B ecommerce guide: https://www.bigcommerce.com/articles/b2b-ecommerce/
ITPro MACH architecture limitations: https://www.itpro.com/software/what-is-mach-architecture
Medusa modules documentation: https://docs.medusajs.com/learn/fundamentals/modules
Medusa workflows documentation: https://docs.medusajs.com/learn/fundamentals/workflows
MACH vs composable commerce: https://gmi.software/blog/mach-vs-composable-commerce-ecommerce
MACH B2B ERP/PIM integrations: https://gmi.software/blog/mach-b2b-ecommerce-integrations-erp-pim
Medusa implementation cost 2026: https://gmi.software/blog/medusa-implementation-cost-2026
MedusaJS development: https://gmi.software/technologies/medusajs
Headless commerce with Medusa: https://gmi.software/technologies/medusajs
Frequently asked questions
- Does GMI Software ever say no to MACH projects?
- Yes. We advise against MACH when there is no product owner, data discipline, KPI, operating team or real constraint in the current platform. A better next step is audit, SaaS hardening, headless-light or DDT before a larger decision.
- Does MACH pay off at 50 SKUs?
- Rarely. The exception is a small-looking catalogue with complex configuration, CPQ, manufacturing, B2B contracts or ERP. For simple 50 SKUs, SaaS usually wins on TCO and time-to-market.
- When should we choose headless-light instead of full MACH?
- When the problem is frontend, mobile performance, SEO, content velocity or analytics, not commerce core, order management or vendor lock-in. Headless-light improves experience and API discipline without full platform migration.
- Which signals mean it is time to revisit MACH?
- Rising integration tickets, manual price corrections, separate web/mobile logic, declining mobile conversion, expensive SaaS workarounds, missing ERP/PIM/WMS integration and platform cost that starts affecting margin.
- Will migrating from SaaS to MACH later destroy data?
- No, if you maintain stable customer, order, product and consent IDs plus API exports from day one. The earlier you clean data, the cheaper a future MedusaJS/MACH migration path becomes.
- How does GMI decide whether MACH pays off?
- We compare 24-36 months of TCO: current SaaS fees, take rates, apps, custom middleware, manual workarounds and cost of inaction versus DDT, development, migration, integrations, hosting, monitoring and maintenance.
Content updated: July 11, 2026