Composable commerce promised freedom. You could pick the best CMS, the fastest search tool, the slickest checkout experience. All modular. All yours. In theory, best-of-breed means never compromising. In reality, it can mean constant juggling, unclear ownership, and platform fatigue before you even launch.

The problem is that a commerce build is by design a mutt. Sure there is thoroughbred blood in the mix but the mixture and combination of great technologies is the point. How do you create the best mutt from impeccable bloodlines is not a challenge dog-breeders face. But IT teams do.  The Marketing Pitch vs. The Operational Reality

The dream goes like this: every vendor in your stack is a category leader. You pair Contentstack or Amplience with Algolia or Constructor, layer in Uniform for orchestration, bring in Dynamic Yield for personalization, and maybe throw in an edge delivery network for performance.

But more tools mean more vendors. More APIs. More SLAs. More platform overhead.

Hidden Costs You Might Not See Coming

Here’s where we see best-of-breed become a burden:

• Integration drag: Most tools work well alone. Together, they need glue. If each integration was built by a different team at a different time with different priorities, that glue can be more of a Post-It note.
• Internal context switching: If the build was not co-ordinated and decisions made about where everything should live that merchants want to do, you can end up with five dashboards and workflows, not one.
• Contract sprawl: You’re negotiating terms, renewals, and support channels across multiple vendors and potentially partners. The aim of composable is fungibility, but do you really have the energy to replace everything if it’s not perfect. 
• Testing complexity: You’ll need to QA not just the tools but the way they talk to each other. That can be hard with multiple ways of creating Dev and Staging environments. It needs thoughtful automation. 
• Ownership confusion: Who’s on call when the PDP fails to render? Is it the front end, CMS, search, or all three? How do you manage triage when everything is interdependent?

Best in Breed v Good Enough

Not all pain is worth avoiding. If the best way to do things was easy, everyone would do it. But if you are going to make decisions around which technologies to emphasize, which to spend time and money co-ordinating then you need to have a way of judging whether the time and effort is worth it. So start there. 

• Does this improve time to market?
• Is there tangible commercial upside I can measure?
• Will this reduce long-term technical debt?
• Can my team operate it without weekly calls to support?
• Do we really need this level of control here?

Tools should be enabling outcomes. Not just checking boxes.

Putting Boundaries Around Your Stack

One of the best things you can do is define lanes. Distinguish right away where you want best in breed and where you want good enough. Some will be different depending on circumstance. 

• Core platform services: These are non-negotiable. Commerce engine, CMS, search. (Though CMS and search will be more or less important depending on how much content and how many SKUs you are talking about).
• Strategic enhancers: These add real business value but can be swapped later. Personalization, recommendations, PIM, payments.
• Nice-to-haves: That animation layer or orchestration layer or Storybook integration might be cool. But it better earn its keep and not overcomplicate other parts of the stack..

Every tool in your stack should have a reason to exist beyond being "the best."

The Decomposable Stack

Many customers should really think first about creating a stack that is decomposable rather than composable. It’s one of the weaknesses of Shopify that there are chunks of the platform that are too difficult to decompose. Checkout is the most obvious, but most enterprise-scale customizations are at least as complex on Shopify as on SFCC.

Happily the vendors in play are now all competing to offer multiple functionality within your stack and where you don’t believe you need (or are yet ready) to take on the co-ordination costs of neatly siloed partner tech, you can usually squeeze great value out of a part of the stack you value already. Contentstack’s personalization technology is fine. Salesforce’s search can be good enough. Amplience’s DAM and AI capabilities work well. 

Sometimes, good enough beats best if the price of best is co-ordination tax that you can’t afford. A slightly less powerful tool that is pre-integrated cleanly can save you months. The beauty of composable is not necessarily what you do at launch but how you use the freedom the stack creates as you gain experience in the reality of a more flexible stack and how you want to compete.

Building a Composable Stack That Works in Real Life

At 64labs, we help customers prioritize. Not all tools are created equal. Not all need to be replaced. A smart composable strategy means knowing where to customize and where to standardize.

We focus on:

• Launch velocity
• Marketing autonomy
• Long-term maintainability

That means saying no to tools that add overhead without a clear return. It means coaching clients to resist the urge to over-engineer.

Composable commerce works when you design the stack with intent and a clear grip on the big picture of what can and should be achieved right away and what can be decomposed later. 

Best-of-breed is not a shopping spree. It’s a discipline. If you want real agility, focus your stack. Choose fewer tools. Choose the right ones. And build a system your team can actually run without a map.

Composable commerce delivers speed, flexibility, and long-term control. But it also requires teams to think and operate differently. That shift is usually welcome. It can also be demanding. We’ve seen great teams stall out not because the tech was flawed, but because their internal structure wasn’t ready to support the pace and complexity that composable requires.

This article isn’t a warning. It’s a playbook for keeping your team energized, focused, and aligned from kickoff to post-launch.

Composable Projects Move Fast When Teams Are Ready

A good composable project launches in five to seven months. That’s aggressive compared to traditional replatforms. But composable projects also require more upfront decision-making across roles. Headless front ends, modular services, and third-party CMS and search tools all demand active, cross-functional input.

When everyone is aligned, it works beautifully. The velocity feels real. The energy builds. But if roles are unclear or teams are out of sync, decisions bottleneck and projects drag.

Why Teams Lose Momentum in High-Change Builds

Here are a few of the most common causes:

• Unclear ownership: Who owns CMS setup? Who defines search behaviors? Who gets final say on navigation? Who is herding the cats on the client team? Who on the partner side is co-ordinating the relationship? With whom?
• Decision fatigue: Composable means choices. Tools, vendors, models, workflows. It’s easy for teams to lose momentum when everything feels undecided or when it seems like critical decisions are being made at an unfamiliar velocity. 
• Marketing and IT misalignment: One wants control. The other wants stability. Without shared understanding, neither gets what they need.
• Partner overload: Bringing in multiple vendors answering to a client for one build can strain bandwidth if internal leaders don’t have time to coordinate across them.

None of these are deal-breakers. But left unchecked, they make even great technology feel hard to adopt.

What It Looks Like When Team Energy Is High

When a composable project is flowing, it shows. Teams are making decisions quickly. Marketing is using the CMS early. Developers are shaping a front end that matches the vision. There’s a clear sprint cadence. Questions have owners. Decisions have deadlines. Demos feel like progress, not just status.

If your internal team looks like that, you’re in great shape.

Clear Structures That Keep Velocity High

A few principles we’ve seen work:

• Designate a single product owner: Someone with authority, not just visibility or a certificate. This person arbitrates across stakeholders and clears blockers fast. This person should be a little bit frightening to their colleagues but relentlessly accountable for the progress of the project and the things that get in the way.
• Map early who owns what: Be honest about it. Don’t say that someone is responsible for someone else if, in the end, the someone else can turn up and change things later on. That’s not ownership. You need people who when they participate in a decision will make it hold. Define who owns the scope of the CMS build and how they are going to manage it. Who trains on search? Who manages the stream of merchant requirements? Don’t wait until sprint five to figure it out.
• Timebox decision windows: And mean it. You can always optimize later. A fast imperfect decision beats a slow perfect one that never ships.
• Build a joint QA process: IT and marketing will both need to validate components. Build the rhythm into your timeline early and make effective QA processes (not just a headcount) a critical requirement you demand from a partner.

How the Right Partner Keeps Your Team in the Flow

Good partners don’t just scope and write code. They stabilize the decision-making structure. They flag when teams (theirs included) are dragging or when accountability is unclear. They train as they go so internal teams aren’t left catching up after launch.

They also build to a cadence. Better velocity comes from repeating a way of doing things and squeezing out inefficiencies over time. 64labs projects always have a predictable rhythm: planning (across five statuses for each story), backlog review and estimation, engineering commitments, daily accountability, rarely blocked multi-functional flow. Sprint0. Then Scopotype. Then Build to Launch. It goes fast. It is easy for clients to fit into. It gets the job done and makes everyone look good.

Partners should give your team energy, not drain it.

Building Internal Confidence Before and After Launch

Composable puts more tools in your hands. That’s a win. But it also means your team needs to be comfortable using them.

Training isn’t a post-launch event. It happens in every sprint. By the time the site goes live, your team should feel like they already run it. Because they do. But to make this work make sure you have prepared the people you want on the project to have sufficient skills to operate with the partner team building the project. Being an intern that makes the coffee for everyone else isn’t going to work. They have to be able to contribute and ask smart questions.

Post-launch support shouldn’t just be bug fixing. It’s coaching, roadmap review, and iteration planning. If your team is energized after go-live, it means the build process worked.

{{banner}}

Composable commerce works best when your team is clear on their roles, confident in their tools, and supported by a partner who knows how to keep the build moving. Technology can accelerate outcomes. But team energy determines how far and how fast you’ll go.

Set the structure right early, and the rest follows.

The MACH Alliance had the acronym, the swagger, and a damn good mission. It stood for Microservices, API-first, Cloud-native, and Headless. The idea was to push the e-commerce world away from monoliths and toward a modular, best-of-breed stack. For a while, it looked like it was going to work.. Vendors joined. Events got crowded. Whitepapers landed in inboxes like fragrant rose petals. It felt like a movement.

But here in 2025, the shine has dulled. MACH Alliance mentions have slowed to a trickle. Retailers aren’t opening RFPs with the acronym circled in red ink. The website still exists, but you’d be forgiven for wondering whether MACH is a revolution that quietly stopped revolving.

So What Happened?

Let’s start with the truth that no one at MACH wants to admit: most retailers don’t have a MACH problem. They have an ROI problem, a velocity problem, and a bandwidth problem. They need to move faster, convert more customers, and do it without tripling their headcount or budget. MACH promised architectural freedom. Retailers needed business agility.

Composable Is Still Thriving

Composable commerce is still very much alive. In fact, it’s thriving. At 64labs, we’ve implemented ten full composable storefronts for brands on Salesforce Commerce Cloud alone. But what wins in the market today isn’t dogmatic adherence to MACH principles. It's a practical, performance-driven composable strategy. That doesn’t always line up with the idealism MACH was selling.

Take microservices. Sounds great in theory. Break everything into modular pieces that can be swapped and optimized. But in practice, who’s got the team to manage dozens of services, each with its own SLA and quirks? Most ecommerce teams need fewer moving parts, not more. Smart composable builds cluster services logically. They minimize overhead while unlocking flexibility where it matters.

Headless? We’re all in. But headless for the sake of headless is a mistake. You need a head that performs, that loads in milliseconds, and that your marketing team can actually use without begging IT. That’s why we partner with tools like Amplience, Contentstack, Dynamic Yield, and Algolia. Not because they’re MACH-certified, but because they make our clients’ lives easier and deliver results.

Cloud-native? Sure. But let’s not pretend this is some radical stance in 2025. Everyone is cloud-native now. If you’re not, you’re either Oracle or a hobbyist. 

API-first? Of course. But Salesforce’s OCAPI has been around longer than MACH itself. These aren’t differentiators anymore. They’re table stakes.

What Retailers Actually Need

What retailers really need is a partner who understands how to make composable commerce deliver ROI fast. They want bounce rates down and conversion rates up. They want to launch campaigns in days, not weeks. They want to test personalization and AI features without rewriting the whole front end. MACH never showed them how to get there. It just handed them a really cool toolbox with a bunch of very expensive tools.

The CEO of ecommerce platform Vtex Mariano Gomide de Faria, who suspended their membership of MACH Alliance this year, summed up some of the reasons they made the switch.

• Integration Complexity: Organizations face overwhelming challenges trying to connect a myriad of APIs and vendor solutions, leading to fragile systems where small changes can cause widespread failures.
• Surging Costs: The cost of integrating, licensing, and maintaining multiple systems often far exceeds expectations. Businesses find themselves distracted from their core mission and end up spending heavily on ongoing operations and vendor management.
• Operational Burden: The fragmented nature of best-of-breed solutions results in disconnected workflows, forcing business users to juggle multiple interfaces. This slows productivity, increases training costs, and damages business agility.
• Security and Privacy Weaknesses: Data is often unnecessarily duplicated across platforms, exposing organizations to compliance and privacy risks. Managing security across many vendors is extremely difficult and can result in regulatory gaps.
• Dogmatic Ideals vs. Business Value: MACH principles, while now common in web app development, are criticized as having become dogmatic, focusing more on technical ideals than on delivering real business outcomes.

Why Salesforce Quietly Pulled Ahead

This is where Salesforce Commerce Cloud has quietly pulled ahead. It didn’t join the MACH Alliance. It didn’t need to. It just evolved. It became de-composable which actually fits better with how customers actually approach a composable journey. Today, SFCC supports headless builds, open integration, and structured APIs. And it’s got a composable storefront accelerator that lets brands move quickly without sacrificing scale. That’s why we’ve seen brands like Moncler, Sweaty Betty, and Iceland go composable with Salesforce and win.

The Legacy of MACH

MACH’s real legacy might be that it created the space for composable to become mainstream. It shifted the conversation. It made monoliths feel like legacy tech. But the Alliance lost momentum because it clung too tightly to its acronym. The future of commerce isn’t about boxes checked on a technical spec sheet. It’s about what actually works.

So if you’re a retailer wondering what happened to the MACH Alliance, here’s your answer: it served its purpose. But the future belongs to brands and partners who can execute. Not just theorize. Not just rebrand old tech with a shiny acronym. The winners are the ones who get composable done fast, clean, and in a way that puts marketers back in control of their digital experience.