Commerce architecture debates optimize for the wrong thing entirely. The only question that matters is whether your platform delivers outcomes or just complexity.
Technology is supposed to be the accelerant. For too many organizations, it has become the anchor.
Commerce platforms chosen to drive growth are quietly doing the opposite: slowing launches, inflating costs, and fragmenting the very experiences they were purchased to improve. The evidence is no longer anecdotal. Research shows that 56% of organizations regret their largest tech purchase in the last two years. In a market where speed and experience quality are the primary competitive levers, that is not a statistic about technology. It is a verdict on how technology decisions get made.
The culprit, in most cases, is not a bad vendor. It is not a failed implementation. It is an architectural philosophy chosen for its promise rather than its proof, adopted before the organization understood what it was actually signing up for, and defended long after the evidence said otherwise.
The commerce stack debate has been framed as a choice between rigidity and freedom. That framing is wrong, and the cost of believing it is measurable.
The Flexibility That Isn't
Composable architecture has a compelling pitch, and it’s not hard to see why it lands.
On paper, it’s pure optionality: break commerce into services, pick best-of-breed components for search, cart, payments, content, fulfillment, and swap parts in and out as your needs evolve. No “suites,” no lock-in, no waiting for a platform roadmap. Just clean APIs and speed.
That’s the story.
The lived experience is different. Flexibility doesn’t disappear in an over-composed stack, it just gets converted into coordination. Every new capability turns into a multi-party alignment exercise: vendors, internal teams, integration layers, release schedules, governance, security reviews, observability, and the part nobody puts in the architecture slide, who owns the experience when something breaks across three systems.
And the people who feel the friction first are rarely the architects who designed it. It’s the marketing team that can’t run a promotion without a development ticket. It’s merchandising, bouncing between tools that weren’t designed to work as one. It’s product teams watching competitors ship improvements while they’re still negotiating dependencies and chasing regressions across a maze of services.
This is where the “agility” pitch starts to unravel. The stack may be modular, but the business isn’t. Commerce outcomes, conversion, order value, on-time fulfillment, customer satisfaction, don’t arrive in microservices. They arrive as an end-to-end experience. When you over-decompose the platform, you don’t just distribute functionality; you distribute accountability.
What makes this trap so expensive is that it’s slow-moving. Early on, composability feels like control. Teams love choosing every component. They can point to a cleaner architecture diagram. They can say, “We’re future-proof.”
Two years later, the future shows up as integration debt, vendor sprawl, and engineering capacity that’s increasingly spent keeping the stack upright instead of pushing the business forward. And unlike a monolith, which at least fails in one place, an over-composed stack fails in ways that are harder to diagnose and even harder to unwind. You don’t just fix a bug; you chase a chain reaction.
So yes, there’s freedom. But it’s the kind that comes with constant overhead. And overhead is not the same thing as speed.
The Bill That Arrived is Usually Larger than Expected
The financial reality of over-composition is not an implementation problem. It is a structural one, and it compounds quietly until it cannot be ignored.
According to Incisiv research, 37% of technology buyers report that a pure microservices approach has led to higher maintenance costs, while 40% report higher training costs. These are not one-time line items absorbed during a replatforming project. They recur annually, growing proportionally as the stack grows, quietly consuming the budget that was originally earmarked for customer-facing innovation.
The cost surface is wider than most finance teams anticipate at the point of platform selection. Integration and maintenance costs for separate components accumulate before the first major campaign launches. Specialized talent capable of managing fragmented systems commands a significant premium and proves difficult to retain when the work is largely maintenance rather than creation. Governance breaks down as accountability distributes across multiple vendors, each with partial visibility into the system and limited responsibility when something fails.
Implementation timelines extend further than projected because component coordination adds overhead to even routine updates. Technical specialists spend a disproportionate share of their capacity maintaining integrations rather than building the differentiating capabilities the business actually needs. And as the system grows more complex, its ability to scale becomes compromised: a stack overloaded with custom connections struggles to adapt when market conditions shift, forcing costly rework or locking organizations into patterns that no longer serve them.
The result is a technology organization caught in a permanent tension between maintaining what exists and building what is needed. Innovation lags not because of a lack of ideas, but because the underlying architecture consumes the resources that ideas require.
What was sold as a platform for growth becomes, in practice, an operational tax on every decision the business tries to make.
The Wrong Question Has Been Driving the Right Conversation
All of that cost, the maintenance burden, the talent drain, the innovation lag, exists because the architecture debate started with the wrong question. It has been asking which approach wins. It should have been asking what winning actually looks like.
Forrester has warned that one-third of digital businesses will regret playing "software company." That prediction is not about microservices or monoliths specifically. It is about organizations that optimized for architectural purity and lost sight of the outcomes that commerce technology actually exists to deliver.
Those outcomes are four, and they are not complicated. Faster time-to-market: the ability to deploy new capabilities before the competitive window closes. Customer experience quality: the ability to create personalized, cohesive journeys that customers notice and value. Cost efficiency: the ability to scale operations without proportional cost increases. Revenue growth: the ability to pursue new business models, channels, and markets without the architecture becoming the constraint.
Every platform decision that cannot be traced back to at least one of those four outcomes is a decision made for the wrong reasons. Every architectural debate that does not start and end with those metrics is a debate about the wrong thing.
The organizations consistently outperforming their peers are not the ones with the most sophisticated architecture. They are the ones with the most disciplined question: does this platform remove barriers to execution, or create new ones? They understand that a balanced approach, with an integrated core where essential commerce functions work together by design, combined with selective flexibility precisely where differentiation matters most to customers, delivers against those four outcomes more reliably than either extreme.
Monolithic rigidity cannot adapt. Over-composed fragmentation cannot focus. The middle path is not a compromise. It is a strategic choice made by organizations that understand what commerce technology is actually for.
Architecture is a means. Outcomes are the point. The moment a business forgets that distinction, the bill starts accumulating, and it rarely announces itself until the damage is already done.
Most Leaders Are Measuring the Wrong Thing
The audit that most commerce organizations have never done is also the one that would tell them the most: a backwards evaluation of what the current stack actually delivers against what it originally promised.
Not which architecture it uses. Not how many APIs it exposes or how many vendors contributed to its assembly. What it delivers, measured against the four outcomes that matter.
Where are launches slower than competitive reality demands? Where are costs scaling faster than the revenue they were supposed to enable? Where does customer experience innovation stall, not because of a lack of strategic vision, but because the underlying systems cannot execute it without months of integration work? Where are technical teams spending their best hours maintaining a stack rather than advancing the business built on top of it?
These questions are uncomfortable precisely because the answers are often already known. The gap between architectural ambition and operational reality tends to be visible to the people closest to the work long before it surfaces in board-level conversations. The audit is not a discovery exercise. It is a permission structure for acting on what the organization has already learned.
For leaders ready to move from diagnosis to a clear framework for action, Incisiv's industry brief developed in partnership with VTEX, "Beyond Technology Hype: Is Your Commerce Stack a Launchpad or a Liability?" maps the full commerce platform landscape, defines the real and compounding costs of over-composed architecture, and lays out the principles of a stack built for outcomes rather than ideology.
The architecture debate will keep going. The businesses that win will be the ones that already moved on from it, because they were too busy compounding the outcomes that debate never once produced.
