Composable solved the monolith. It created an integration problem.

Commerce platforms, order management and the operational systems that carry a peak trading day.

A shopkeeper in a pink shirt standing among shelves of brightly coloured stock

Where we help

The work we are asked to do in retail & e-commerce.

01

Composable and headless builds

MACH architecture assembled so the seams are owned rather than discovered.

02

Order management

The reconciliation layer that quietly decides whether the customer gets their parcel.

03

Peak readiness

Load modelling and cost control for the day the year is decided on.

04

Unified customer data

One view across online and store that the merchandising team can query.

05

Store and fulfilment systems

Tools for the people picking, packing and serving in store.

The numbers behind our retail & e-commerce work

Composable commerce solved the monolith problem and created an integration problem. Every MACH stack we have inherited has the same weak point: order management, doing quiet reconciliation work that nobody scoped and nobody owns. It surfaces as a support queue rather than an architecture decision, which is why it stays unfixed. We scope it explicitly, before the first vendor is chosen.

1.2M sessions

the load we have held

+21%

what it moved

15

years building for retailers

Selected work

Engagements in retail & e-commerce, described rather than named.

Questions we get asked

Can you handle peak trading?

Peak readiness is a programme that starts months before the day. Load testing against realistic baskets, dependency mapping so a slow third party degrades instead of cascading, and a freeze plan everyone agreed in advance. The failures we are called in after are almost never the storefront itself.

We are on a composable stack. Can you work with it?

Yes, and we usually find the weak point in the same place. Composable solved the monolith and created an integration problem, and order management is where it concentrates — quiet reconciliation work that nobody owns until something goes wrong on a Saturday. That is where we tend to start.

Should we replatform or improve what we have?

Improve, unless the current platform is genuinely preventing something the business needs. Replatforming consumes a year and usually buys back the position you already held. We look for what is actually blocked — a channel you cannot launch, a market you cannot enter — before proposing a rebuild.

Can you connect our online and in-store systems?

That is most of what retail engineering turns out to be. Inventory, orders, returns and customer identity each exist in more than one system with different rules, and the work is deciding which one is authoritative for each. We settle that before building anything on top.

How do you avoid overselling stock?

By treating inventory as a distributed-systems problem, which is what it is. Near-real-time synchronisation between channels, durable event processing so nothing is lost on a restart, a reconciliation sweep to catch drift, and automatic handling for the sale that slips through anyway.

How quickly can you move?

10 wks to a first release, and the constraint is usually integration access rather than build time. Getting credentials and test environments from an existing platform vendor is the step that most often sets the timeline.

A shopkeeper in a blue shirt in front of shelves packed with brightly coloured goods

Let's talk about who owns order management.