How composable architecture saved a client project

Has your platform ever felt like it's working against you rather than for you? Late last year, a client came to us with a problem. Their e-commerce site was built on a monolithic platform that handled everything, CMS, product catalogue, checkout, email marketing, the lot. It had worked well enough when they launched three years earlier, but the business had outgrown it. The CMS couldn't handle their content requirements. The search was slow. The checkout conversion rate was poor. And every change, no matter how small, required their platform vendor's involvement at £150 an hour.

The monolith problem

The issue with monolithic platforms isn't that they're bad, many are genuinely excellent for their intended use case. The problem is that they assume your needs will fit their model. When they do, everything works smoothly. When they don't, you're fighting the platform. This client had hit that point on multiple fronts: they needed a content model the CMS couldn't support, search capabilities the built-in search couldn't deliver, and a checkout flow the platform's templating system couldn't customise.

The obvious options were: live with the limitations, customise the monolith beyond its comfort zone (expensive and fragile), or start over on a different monolith (expensive and risky). None of those were good.

The composable approach

What I proposed instead was a composable architecture, replacing individual pieces of the monolith with best-in-class tools, connected via APIs, without having to replace everything at once. I started with the two biggest pain points: content and search.

I migrated the content layer to Sanity. This gave the marketing team the structured content modelling they needed, real-time collaboration, and the ability to publish without developer involvement. The existing platform's CMS was bypassed entirely, Sanity served content via API to the front end, while the monolith continued handling commerce.

For search, I integrated Algolia. The product catalogue was synced from the e-commerce platform to Algolia, which provided instant, typo-tolerant, filterable search. The improvement was dramatic, search result pages that used to take 2-3 seconds loaded in under 200 milliseconds.

Phase two: the front end

With content and search decoupled, I built a new front end in Next.js that pulled from Sanity for content, Algolia for search, and the existing platform's API for product data, cart, and checkout. This gave me full control over the user experience, page speed, design, mobile experience, while keeping the commerce backend intact.

The thing I'd want you to take away was that we didn't have to replace everything on day one. The monolith still handled orders, payments, inventory, and fulfilment, the things it did well. We only replaced the parts that weren't working. Over time, if the client outgrows the commerce backend too, that can be swapped out without touching the front end or the CMS.

The results

Page load times dropped by 60%. Search engagement increased by 40%. The content team went from publishing once a fortnight (because it was painful) to publishing twice a week. And the client's dependency on their platform vendor dropped from 20 hours a month to about 4.

Is composable right for everyone?

No. If a single platform does everything you need, use it. Composable architecture adds complexity, more services to manage, more integrations to maintain, more things that can fail independently. It's worth that complexity when a monolith is genuinely holding you back, and when the business is large enough to justify the investment. For a small business with straightforward requirements, a monolith is probably still the right choice.

If your platform is starting to feel like a constraint rather than a foundation, I'd welcome a conversation about what composable might look like for you. Get in touch at [email protected].