By Diosh — Founder, AHAeCommerce | eCommerce decision intelligence for $50K–$5M GMV operators
You are being pitched composable, API-first, MACH commerce as the modern architecture, and monolithic platforms like Shopify as legacy weight you will eventually outgrow. The pitch is not wrong about the technical capability. It is wrong about what it costs you to keep that capability working. This is a trade-off piece for operators in the $5M–$30M GMV band with a technical lead, deciding whether to migrate off a monolith. The trade is not "modern versus legacy." It is flexibility and best-of-breed components on one side, against permanent engineering payroll to maintain the connections between those components on the other. By the end you should be able to size your own engineering capacity honestly and pick the side that matches it — not the side with the better deck.
The Real Question Is Not "Which Architecture Is Modern"
The composable pitch frames the decision as a timeline. Monolithic platforms are positioned as where commerce was; API-first composable architecture is positioned as where commerce is going. Frame it that way and the answer is predetermined — nobody wants to buy the past.
But "modern" is not a property the architecture has on its own. A composable stack assembled from a commerce engine, a separate content management system, a separate search provider, a separate cart-and-checkout service, and a separate frontend is only "future-proof" while every one of those connections keeps working. Each connection is a contract between two vendors who do not coordinate their release schedules. When one side ships a breaking change, the contract breaks, and the architecture stops being modern and starts being broken until someone fixes it.
That someone is you. This is the substitution the pitch performs and never names: a monolith hides its integrations inside one vendor's codebase, and that vendor owns the breakage. A composable stack exposes every integration as a seam you own. The Gartner research on composable commerce is explicit that the model assumes "fit-to-standard" discipline and internal technical ownership — it is an architecture for organizations that have engineering capacity to spend, not a default upgrade path. The decision is therefore not about modernity. It is about whether you have, and want to permanently fund, the team that owns the seams.
That reframing is the whole article. Everything below is sizing the bill.
What API-First Composable Commerce Actually Buys You
The flexibility is real, and it is worth being precise about, because the failure mode is dismissing the upside, not just the cost.
Best-of-breed component selection
In a composable model — formalized by the MACH Alliance as Microservices, API-first, Cloud-native, and Headless — you choose each piece independently. You can run a commerce engine like commercetools for catalog and pricing, a dedicated search provider tuned for your category, a headless CMS your content team actually likes, and a custom frontend built on a framework like Shopify's Hydrogen or a fully bespoke stack. No single vendor's weakest module forces a compromise on you. For a brand whose competitive edge genuinely lives in one component — a $20M GMV brand whose entire conversion advantage is a configurator no off-the-shelf platform supports — that independence is not a luxury. It is the reason to migrate at all.
Independent scaling and deployment
Because components are decoupled, you scale and deploy them separately. Your search tier can absorb a traffic spike without touching checkout. Your frontend team ships a redesign without waiting on a platform release window. A monolith couples these — a platform-wide deploy touches everything, and you move at the vendor's cadence. For a team large enough to run parallel workstreams, decoupling removes a real bottleneck.
Escape from platform lock-in — partially
Composable advocates promise freedom from lock-in, and there is truth in it: you can swap a search provider without re-platforming the whole business. But the lock-in does not disappear. It moves. You are now locked into the integration layer your own team built — the glue code, the data-mapping conventions, the event contracts between services. That layer is bespoke, undocumented by any vendor, and understood only by the engineers who wrote it. We cover where that buried cost accumulates in eCommerce tech debt. The honest summary: composable trades vendor lock-in for self-built-integration lock-in. Whether that is a better trade depends entirely on your engineering bench.
The Integration-Maintenance Tax Nobody Quotes You
Here is the line item the pitch leaves off the page. Every seam between two components is a thing that can break, and every break is yours to fix.
Every component upgrade can break a seam
Each vendor in your stack ships updates on its own schedule. Your commerce engine deprecates an API version. Your search provider changes a response schema. Your CMS alters how it returns structured content. Any one of these can break the integration that depends on it — and you will frequently learn about the break in production, because no vendor tests their release against your specific glue code. A monolith absorbs this internally; its vendor regression-tests its own modules against each other before shipping. In a composable stack, that cross-component regression testing is a job you now staff. We size this directly in the integration tax, and the short version is that integration maintenance is not a one-time migration cost — it is a recurring operating expense that scales with the number of components you run.
You own every seam, permanently
Count the connections, not the components. Five components do not mean five things to maintain; they mean up to ten or more pairwise integrations, plus the orchestration layer that coordinates them. Each is a surface that needs monitoring, error handling, retry logic, and an on-call human when it fails at 2 a.m. during a promotion. IBM's widely cited security and operations research has repeatedly put the cost of unplanned digital downtime well into thousands of dollars per minute for revenue-generating systems (IBM); for a commerce operator running a flash sale, a broken checkout seam is not an engineering ticket, it is lost orders measured in real money per minute. The monolith operator escalates that to their platform's support line. The composable operator is the support line.
Sizing the team that the architecture requires
As a planning estimate — and you should treat it as an estimate to pressure-test against your own stack, not a guarantee — credibly running a composable commerce architecture in production tends to require a standing engineering team of roughly three to five people: someone who owns the integration and orchestration layer, frontend ownership for the custom storefront, and DevOps/platform reliability for monitoring and incident response. Loaded, that is commonly a $400K–$700K annual payroll line in most North American markets before you have sold a single additional unit, and it does not shrink after launch — maintaining seams is steady-state work, not a project that ends. If your honest answer to "can we fund this permanently" is no, the architecture is not future-proofing you. It is a liability you have not finished pricing. The eCommerce platform decision framework walks through how to put this number next to your contribution margin before you commit.
What Monolithic Commerce Trades Away — And What It Keeps
Monolithic platforms — Shopify, BigCommerce, and the like — are not the absence of a choice. They are a different, deliberate trade.
What you give up
You accept the platform's opinions. Its checkout flow, its admin model, its data structure, and its release cadence are largely fixed. If your business needs a capability the platform does not offer and its app ecosystem does not cover, you are constrained — you cannot independently swap in a best-of-breed component the way a composable stack can. For a brand whose differentiation genuinely depends on a capability the monolith cannot express, that ceiling is real and worth taking seriously. That specific situation — a real capability gap, not a preference — is the legitimate trigger to consider building, which we treat carefully in custom eCommerce: when to build.
What you keep
You keep operational simplicity, and at $5M–$30M GMV that is not a consolation prize — it is often the higher-value side of the trade. One vendor owns the integration between catalog, cart, checkout, payments, and admin. When something breaks, you file a ticket; you do not staff an incident. Upgrades arrive tested against the rest of the platform. Your team spends its hours on merchandising, acquisition, and margin — the things that actually move the business — instead of on keeping seams from tearing. Adobe's commerce trend research has consistently found operational and conversion execution, not raw architectural flexibility, to be the dominant driver of growth at this revenue band (Adobe). A monolith lets a lean team execute on exactly those levers without funding a platform team to do it.
The headless middle ground
There is a third position worth naming: a monolithic backend with a headless, decoupled frontend — Shopify plus Hydrogen, for example. You get frontend flexibility while the vendor keeps owning the hardest integrations behind the cart. It is a narrower, cheaper version of the composable trade, and for many teams it is the right amount of decoupling. Who actually needs it, and who is buying complexity they will not use, is the subject of headless commerce: who needs it.
How To Decide: Match The Architecture To Your Capacity
Stop evaluating architectures in the abstract. Evaluate them against your specific engineering capacity, because that is the variable the pitch is engineered to make you ignore.
Run the capacity test first
Before you compare features, answer one question honestly: do you have, today, three to five engineers you can permanently dedicate to integration and platform reliability — not borrow from product work, but dedicate? If the answer is no, and you have no funded plan to hire them, the composable evaluation is over. You do not have the team the architecture requires, and adopting it anyway means you will own every seam break with nobody staffed to catch it. Pick the monolith. This is not settling; it is matching the tool to the operation.
Run the differentiation test second
If you do have the capacity, ask the second question: does your competitive advantage genuinely live in a specific component that no monolith can express? Not "would flexibility be nice" — flexibility is always nice in a vacuum. The test is whether a single best-of-breed component is load-bearing for your actual edge. If yes, composable earns its tax. If your differentiation is brand, acquisition, merchandising, or service — as it is for most operators in this band — a monolith expresses all of that perfectly well, and the composable tax buys you flexibility you will not convert into revenue.
Price the tax before you sign
If both tests point to composable, do the arithmetic before committing. Put the loaded annual cost of the platform team next to the incremental margin the flexibility will actually generate. If the bespoke component drives a measurable conversion or margin lift that exceeds the standing engineering cost, the trade is sound. If you cannot draw a straight line from the architecture to a number on your P&L, you are buying "future-proof" as a feeling, and feelings do not cover payroll. "Future-proof" is only true if you permanently fund the team that maintains the connections between the parts. Decide whether you are willing to sign that recurring check — and decide it before the migration, not after the first seam breaks during a promotion.
