Imagine you've bought a kitchen. Not designed it - bought it. The whole thing, pre-assembled, from one supplier. Oven, fridge, dishwasher, worktops, cabinets - all from the same manufacturer, all designed to work together. It looks fine. It works fine. Until the dishwasher breaks, and you discover it's been plumbed into a proprietary system that only accepts parts from the original supplier. Who, it turns out, has discontinued that model. And suddenly you're not replacing a dishwasher - you're having a conversation about ripping out half the kitchen.
That's roughly what happens when a monolithic digital platform reaches the end of its useful life. Everything's connected to everything else. You can't change the CMS without affecting the CRM integration. You can't upgrade search without retesting the entire front end. What should be a small, contained improvement becomes a programme of work that costs £150k and takes the best part of a year. I've watched that conversation happen more times than I'd like.
Composable architecture is, at its simplest, the idea that you don't have to buy the whole kitchen from one supplier. You pick the best oven, the best fridge, the best dishwasher - each from a specialist - and connect them through a shared set of standards. If one breaks, you swap it. If something better comes along, you switch it in. The rest of the kitchen keeps working.
That's the promise, anyway. And for the right organisation, it's a genuinely powerful way to build and evolve a digital platform. But I want to be honest upfront: composable isn't the answer for everyone. For some firms, it introduces more complexity than it resolves. And the difference between those two outcomes usually comes down to a few very specific factors that have nothing to do with technology preferences.
Let's get specific, because "composable" has been thrown around in vendor marketing long enough to lose most of its meaning.
A traditional monolithic platform - your Sitecore, your older Kentico setups, your classic WordPress-with-fifty-plugins - bundles everything together. Content management, front-end design, search, personalisation, analytics, forms - all in one system, from one vendor. The upside is simplicity: one platform, one support contract, one team who knows how it all fits together. The downside is rigidity: when you want to change one thing, you're constrained by everything else in the stack.
A composable architecture takes a different approach. Instead of one system doing everything, you assemble your platform from independent, specialist components - sometimes called "best of breed." Your CMS handles content. A separate service handles search. Another handles personalisation. A dedicated front-end framework controls what the user actually sees. Each component talks to the others through APIs - think of APIs as the standardised plumbing connectors that let you plug different appliances into the same water supply.
The key idea is interchangeability. If your search component isn't performing, you can replace it without touching your CMS. If a better personalisation engine comes along next year, you can swap it in. If you need to add a new channel - a mobile app, a client portal, an internal tool - you can connect it to the same content layer without rebuilding anything from scratch.
This is what people mean when they talk about "headless" CMS, by the way. In a traditional setup, the CMS controls both the content (the "body") and how it's displayed (the "head"). In a headless setup, the CMS just manages content and makes it available through APIs. The front end - the head - is a separate thing entirely, built with whatever technology best serves the user experience. It sounds like a small architectural distinction. In practice, it changes almost everything about how fast you can move.
Here's where things get interesting, because the actual reason composable matters to a managing partner or technology leader isn't the architecture diagram. It's what it lets you do differently as a business.
You can evolve incrementally instead of in big bangs. This is probably the single biggest advantage. With a monolithic platform, change tends to come in large, expensive cycles - the dreaded replatform every four to six years, where you replace everything at once because you can't replace anything in isolation. With composable, you can make meaningful improvements quarter by quarter. Swap the CMS this quarter. Improve search next quarter. Add personalisation the quarter after. Each change is smaller, cheaper, and lower risk.
You reduce vendor lock-in. When your entire digital platform is one vendor's product, that vendor has enormous leverage over your roadmap, your costs, and your options. If they raise prices, you pay. If they sunset a feature you rely on, you adapt. If they get acquired and the product direction changes - which, if you've been around long enough, you've seen happen - you're stuck with it or you start again. Composable doesn't eliminate vendor relationships, but it means no single vendor holds the keys to your whole platform.
You can respond to opportunities faster. When a new channel emerges, or a client expectation shifts, or AI creates a new set of possibilities, a composable platform lets you plug in new capabilities without redesigning the foundation. We've seen this play out quite vividly over the past couple of years with AI. I was on a call earlier this year with a CTO at a mid-sized consultancy who'd spent six months trying to bolt an AI content tool onto their legacy Sitecore setup. Six months. Meanwhile, a similar firm we'd helped move to a headless stack had the same capability running in about three weeks. The difference wasn't budget or ambition - it was architecture. I've written separately about the fragility of digital foundations, and this is one of the places where that fragility becomes most visible.
You get better performance. This is a slightly technical point, but it matters commercially. Composable front ends - typically built with frameworks like Next.js or Astro - are significantly faster than traditional server-rendered CMS pages. Faster pages mean better user experience, better SEO performance, and higher conversion rates. For a B2B service firm where the website is the primary demand generation channel, the difference between a 1.5-second page load and a 4-second page load shows up in enquiries. Not eventually. Now.
Composable sounds like a buzzword. Why can't we just use a single platform that does everything?
Fair challenge. And for plenty of firms, a single platform genuinely is the better choice.
Composable architecture introduces integration complexity. When every component is independent, something has to hold them all together - the APIs, the middleware, the orchestration that ensures your CMS, your search, your personalisation, your analytics, and your front end are all talking to each other correctly. In a monolithic platform, the vendor handles that integration. In a composable setup, you own it. Which means you need people who understand it.
It requires stronger technical capability - either in-house or through a partner. A monolithic CMS like WordPress or a traditional Kentico setup can be managed by a reasonably capable marketing team with occasional developer support. A composable stack needs someone who understands APIs, deployment pipelines, and how different services interact. If your entire digital operation is one marketing coordinator and a freelance developer you call twice a year, composable is going to create problems you don't currently have.
The initial effort is often higher. Building a composable platform from scratch typically takes more upfront planning and development than deploying a monolithic one. You're making more decisions - which CMS, which front-end framework, which hosting approach, how to handle search, how to handle forms - and each decision has implications for the others. That front-loaded complexity pays off over time through flexibility and lower cost of change, but you have to get through the initial build first.
And there's a subtler risk that doesn't get talked about enough: over-engineering. I've seen this go wrong in a fairly spectacular way. A professional services firm we assessed last year had been sold a composable architecture by their previous agency. Seven different services. Four separate hosting environments. A deployment process that required a DevOps engineer every time someone wanted to publish a blog post. The marketing team had basically given up trying to manage the site themselves and were just emailing the agency for everything. That's not composable done well. That's composable done for its own sake, by people who found it interesting to build and didn't much care whether the client could actually run it.
So how do you actually decide? In our experience, composable architecture tends to be the right choice when several of these conditions are true:
Your requirements are complex. You're not just running a brochure website. You've got a client portal, a content hub, integration with your CRM and marketing automation, maybe a knowledge base or resource library with structured taxonomy. The more interconnected systems you have, the more value composable delivers.
You need to serve multiple channels or audiences. If you're delivering content to a website, a mobile app, an internal tool, and a partner portal - or you can see that coming - composable's ability to manage content once and distribute it everywhere becomes genuinely powerful.
You have (or can access) technical capability. This doesn't mean you need a ten-person dev team. But you need someone - internally or through a partner - who can manage APIs, handle deployments, and troubleshoot integration issues. If the phrase "API endpoint" draws blank stares across your entire organisation, address that before you commit to composable.
You're planning to evolve over time. If you're building a platform you expect to iterate on quarter by quarter, adding new capabilities and swapping components as needs change, composable gives you the architecture to do that without major replatforming cycles.
On the other hand, composable probably isn't the right choice when:
Your needs are genuinely simple. A 30-person consultancy that needs a well-designed website with a blog and a contact form doesn't need a composable stack. A good monolithic CMS - Umbraco, WordPress done properly, even Squarespace in some cases - will serve you better, faster, and cheaper.
Your team is small and non-technical. If your digital operation is essentially one person who manages the website alongside everything else in marketing, a composable platform is going to create a dependency on external developers for routine tasks. That's the opposite of what you want.
You don't have a clear integration requirement. If your CMS doesn't need to talk to your CRM, your portal, or your marketing platform, you're adding integration complexity for no practical benefit.
Budget is extremely tight and there's no room for the upfront investment. Composable platforms typically have a higher initial cost and a lower ongoing cost. If you can't absorb the upfront investment, a well-implemented monolithic platform with a clear migration path is a perfectly sensible choice.
This is something we spend a lot of time on at Distinction, because the technology decision is often the easy part. The harder question is whether the organisation is ready for the operating model that comes with it.
A composable platform isn't just a different architecture. It's a different way of working. Content teams need to think about structured content rather than page layouts. Development teams need to manage multiple services rather than one platform. Operations need to monitor integrations, not just uptime. And leadership needs to commit to ongoing investment - small, continuous investment rather than the big-bang cycle, but investment nonetheless.
We use a straightforward maturity assessment to help firms work through this. It covers four areas: technical capability (do you have or can you access the skills to manage a composable stack?), integration complexity (how many systems need to talk to each other, and how well-defined are those connections today?), content operations maturity (is your content team comfortable with structured content and multi-channel delivery?), and organisational commitment (is leadership prepared for continuous platform investment rather than a five-year replacement cycle?).
If a firm scores strongly across all four, composable is usually the right move. If they score strongly on two or three, there's typically a path to composable that starts with some foundational work. If they score weakly across the board - and this happens more often than you'd think - a well-implemented monolithic platform is the better starting point, with composable as a future destination.
I had this exact conversation with a COO at a financial services firm last autumn. They'd been quoted £380k to upgrade their Sitecore instance. She was frustrated, sceptical, and had already half-decided to just pay it. When we ran through the maturity assessment, it became pretty clear that the integration complexity was high but the organisational commitment was low - the leadership team hadn't really bought into continuous investment, they wanted to pay once and be done with it. Composable would have been the wrong answer for them at that point. Not because the architecture was wrong, but because the organisation wasn't set up to get value from it. We recommended a more contained approach: migrate the CMS to headless Umbraco, stabilise the integrations, and revisit the broader composable question in 18 months when they'd built some capability. Total cost: about £95k. She nearly fell off her chair.
The worst outcome is a firm that adopts composable before they're ready and then blames the architecture when things get difficult. It's not the architecture's fault. It's a capability gap that should have been addressed first.
One thing that often gets lost in the composable vs. monolithic debate: you don't have to go all-in on day one. In fact, I'd generally advise against it.
The approach we've seen work best for mid-market firms is what I'd call progressive composability. Start with a headless CMS - something like Payload, Kontent.ai, or headless Umbraco - and a modern front end. That gives you the core architectural benefit (content separated from presentation) without the full complexity of a multi-service composable stack. Then, as your needs grow and your team's capability develops, add specialist services: a dedicated search engine, a personalisation layer, whatever the business case supports.
You can be "a bit composable" - headless CMS with a couple of integrated services - and get 80% of the benefit with a fraction of the complexity. The firms that struggle are the ones who try to jump from a five-year-old WordPress site to a fully composable, microservices-based platform in one go. That's not a technology problem. That's an ambition-to-capability mismatch. And it's an expensive one.
If you've read this far and you're wondering where your firm sits, start with what's actually driving the conversation. Is it a genuine need for flexibility because your current platform can't keep up with what the business needs? Or is it that someone saw a conference talk about composable and thought it sounded modern? Both are valid starting points, but they lead to very different next steps.
Then audit your current integration landscape. How many systems does your digital platform connect to? How well do those connections work today? If the answer is "not many" and "fine," you probably don't need composable yet. If the answer is "seven, and they all break whenever we update anything," you almost certainly do.
And have an honest conversation about capability - not just technical capability, but organisational capability. Does your leadership team understand what continuous platform investment looks like? Is your content team ready to work with structured content? Will your IT governance model support a platform that evolves quarterly rather than every five years?
If you're not sure about any of those questions - that's fine. That uncertainty is exactly what a good assessment is designed to resolve. We run 14-day assessments specifically to help firms work through these decisions before they commit to anything. Because the most expensive composable platform is the one you build before you're ready for it.
There's a companion set of content in Section 4 of The Briefing Room that covers how to build the business case for platform investment and get these decisions over the line internally. If the technology direction is starting to make sense but you're wondering how to get your board or partnership to back it, that's probably your next read.