.png)
Research report
AI Does Not Remove the Bottleneck
Find your real workflow constraints before buying AI tools.
Commerce platforms, order management and the operational systems that carry a peak trading day.
The work we are asked to do in retail & e-commerce.
MACH architecture assembled so the seams are owned rather than discovered.
The reconciliation layer that quietly decides whether the customer gets their parcel.
Load modelling and cost control for the day the year is decided on.
One view across online and store that the merchandising team can query.
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.
the load we have held
what it moved
years building for retailers
Engagements in retail & e-commerce, described rather than named.
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.
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.
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.
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.
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.
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.
.png)
Research report
Find your real workflow constraints before buying AI tools.
.png)
Research report
Don't run your tech stack on unverified SaaS myths.
.png)
Research report
Close the gap between buying AI and adopting it.