Tech debt and complex tech migrations have become major obstacles to successful digital transformations. These challenges stem from the fact that many organizations built their technology infrastructure on legacy systems from a different era. This prevents companies from adopting new technologies that would enable them to respond to fast-changing market trends and customer expectations. To overcome these limitations, many organizations are adopting composable tech stacks—a modern approach to building technology architectures that uses modular, interchangeable components. Instead of relying on a single all-in-one platform, a composable stack allows businesses to select the best tools for each specific need. Components such as content management systems, commerce engines, platforms for enterprise resource planning, and product information management systems are designed to function independently while integrating with other existing modern and legacy systems. This modularity lets organizations innovate faster, replace underperforming tools more easily, and avoid vendor lock-in.
McKinsey’s Melanie Krawina sat down with Sana Remekie, the CEO and cofounder of Conscia.ai, to discuss how composability can accelerate digital transformations and help CEOs derive continued value from their investments in legacy systems.
Melanie Krawina: The terms “composability” and “composable tech stacks” seem to be the new buzzwords in tech. Can you explain what they are?
Sana Remekie: A few years ago, the development community—led by organizations such as the MACH Alliance—introduced the concept of composability. Composability basically means that when you build your technology architecture, you can assemble business capabilities based on a company’s specific needs rather than purchasing a single all-in-one platform that could create vendor lock-in. Beyond that, organizations can connect these independent components without heavy custom code and are able to replace any component of the tech stack without having to refactor everything.
Large and small organizations alike have always tried to make a variety of different technologies work together within their architectures. But these legacy technologies were not built to interoperate, and businesses have needed to write a large amount of custom code to make these systems communicate. To address this challenge, the MACH Alliance proposes the MACH approach: microservices, API-first, cloud-native SaaS [software as a service], and headless architecture. It’s a nimble software development approach that decouples the front-end user interface from the back-end operations of an application, making it easier to incorporate new technologies into the stack. As a result, organizations can achieve greater resilience and flexibility, allowing them to keep pace with rapid innovation and evolving business needs.
Melanie Krawina: Is a composable tech stack only for large organizations that are more digitally advanced?
Sana Remekie: This is an ongoing debate. Many practitioners would say that a company needs to be at a certain size and level of digital maturity to be able to adopt a composable tech stack. The argument is that building a composable tech stack requires a product mindset. Companies need to have the right level of architectural and technical skill sets to successfully address many technical considerations. They need to understand the ins and outs and limitations of each technology, how to make them talk to another, and how to best build a stable, scalable, and performant architecture. And I would say that any business above a certain size, say $250 million in annual revenue, should be well on their way to composable transformation.
But while large enterprises are early adopters of this philosophy, smaller organizations can adopt it, too. Conscia.ai, for instance, is a start-up where we use the MACH principles in everything we build. The only way we could survive in a very competitive landscape was to build a platform that we could easily adapt and build components that we could quickly integrate with other technologies and scale independently.
Midmarket companies could also benefit from some of the elements of composability, but they often opt for ready-made solutions because they don’t have the time, budget, or personnel to define the technology architecture, which is understandable. They want out-of-the-box integrations that they can deploy almost immediately.
Ultimately, composability is a spectrum—there is no need for brands to go all in. They can build on top of what they already have, but as they progress on their composable journey, everyone can benefit from adopting components that follow some basic composability principles.
Melanie Krawina: What business teams are involved in implementing composability?
Sana Remekie: Usually, two sides of the company are involved in a composable transformation: the business side—which includes digital products, commercial, and marketing teams—and the tech and IT side. Let’s say, for example, that the product team wants to release a new AI agent within four weeks because the market is changing quickly, and they want to trial something new and innovative to increase customer satisfaction. The tech teams are then under pressure to develop and integrate this new feature into an existing technology architecture by using a composable approach, which will ensure agility and reliability. This composable technology architecture will enable IT teams to more quickly and easily deliver on features the business teams want, allowing the brand to compete in today’s market.
But for all this to work, and for an organization to successfully adopt composability, implementation needs sponsorship from the executive level. The business case for composability needs to focus on cost efficiency, ROI, a better customer experience, and adaptability.
Melanie Krawina: That makes a lot of sense. Can you explain which back-end systems are required for new front-end features and how they need to work together to deliver the best customer experience?
Sana Remekie: The concept of back end to front end is quite important in a composable stack. The more back ends and front ends a company has, the more it needs a unification or orchestration layer that connects these systems and provides a unified response to every front end. So whether it’s a watch, web interface, mobile app, or AI agent, instead of implementing point-to-point integrations with each back end, the goal is to centrally orchestrate everything to provide a consistent and connected customer experience across touchpoints. We call this the digital experience orchestration layer.
Funnily enough, I recently had an experience that revealed how important the orchestration layer is. While I was waiting for my kids to finish their skating class, I ordered pizza so it would be ready for when we got home for dinner. I had my laptop with me because I usually get some work done while they’re in class. I went to the restaurant’s website, logged in, and ordered pizza. After the class was done, I quickly checked the confirmation email on my phone, which said the order had been placed. As I was driving home, I called the restaurant to check if the pizza would arrive on time, and it sent me to a general help desk representative who asked me where I ordered the pizza from. I had to go through multiple customer service reps to figure out where my pizza was. In those cases, wouldn’t it be nice if, based on my phone number and name, the help desk was able to pull up my order and immediately tell me where it was?
This lack of experience orchestration happens in many situations, some much more mission-critical than ordering a pizza. Both businesses and customers can suffer from the fragmentation of experiences across all channels because companies have back-end legacy systems, such as a CRM [customer relationship management system], that lack real-time integration with customer touchpoints or simply can’t talk to each other. As a result, companies struggle to provide a consistent consumer experience, which means trouble, particularly with the newest Gen Z consumers, who have little patience for companies that can’t immediately deliver what they need.
Melanie Krawina: This is a good segue into the next question. Most of our readers work in large companies where, as you mentioned, there are a lot of legacy systems. How can CEOs start the transformation to a composable tech stack?
Sana Remekie: A composable transformation doesn’t normally require a company to completely overhaul its legacy systems. When speaking with digital executives, I recommend starting transformation work from the outside in. After all, companies serve their customers through front-end interfaces such as a website or mobile application. Thus, instead of immediately replacing their core back-office systems, businesses should start by building an abstraction and orchestration layer between the front-end interfaces and back-end systems. Admittedly, this is the most complex layer, but if you can transform this layer to be more agile, you can swap out back-end systems seamlessly over time.
Melanie Krawina: How do you believe the role of orchestration will change in the brave new world of agentic commerce?
Sana Remekie: Agentic commerce flips the customer journey on its head: Instead of users visiting a site or app, autonomous agents do the legwork: searching, filtering, comparing, and even purchasing on behalf of the customer. That shift makes orchestration the unsung hero of this new paradigm. Most brands can’t keep up because the experience logic is buried in custom code and monolithic commerce suites. An orchestration layer changes that. It unifies data and services across enterprise’s legacy and composable systems, then exposes them as clean, capability-level APIs that any agent can consume. Thus, having a well-architected composable stack will become key in the evolving landscape of agentic commerce.
