We started with good architecture. The hard part was everything else.

The original vision for Supply Lens was clear: an integration platform built on modern, scalable infrastructure — microservices, event-driven messaging, cloud-native deployment — that could connect the systems growing e-commerce and supply chain businesses depend on, without the rigidity and cost of traditional middleware.

The architecture held up. What we underestimated was the sheer variety and messiness of the real world that sits on the other side of every API call. Not the technical connections — those we could handle. The business logic. The exceptions. The retailer-specific quirks. The operational rules that exist in someone's head and nowhere in a specification document.

Three years in, the platform is considerably stronger than it was at launch. Not primarily because we added more infrastructure — though we have — but because we've developed a much deeper understanding of what integration actually requires when it has to work reliably, every day, for businesses that can't afford for it to fail.

175+
Platforms and systems connected
50+
Retail EDI trading partners supported
99.9%
Uptime across monitored integrations

Six things three years of real-world integration teaches you

Reliable delivery matters more than impressive architecture

Early on, we were rightly focused on building infrastructure that could scale. The lesson that followed was humbling: customers don't care how the infrastructure is designed. They care that their orders process, their stock levels update, and their despatch confirmations reach the right place. An elegant distributed system that fails silently is far worse than a simpler system that surfaces errors immediately. We rebuilt our monitoring and alerting layer twice to get this right. We're glad we did.

Configuration depth is the actual product

A connection between Shopify and Unleashed sounds simple. In practice, it involves decisions about customer creation strategy, tax handling, warehouse routing, shipping method mapping, SKU match logic, inventory source, and what happens when an order contains a product that doesn't exist in the ERP. Businesses vary enormously on every one of these decisions. The platform's ability to handle that variation without custom development for each customer — that's the product. The API connections are just the plumbing.

The edge cases are not edge cases

We stopped using the phrase "edge case" internally some time ago. What appears to be an unusual scenario on a first call — a partially fulfilled order, a product sold in different units on different channels, a depot that appears under two different GLN references in the same retailer's system — turns up on the second live week for almost every customer. These aren't exceptions. They're the operational reality of running a business. The integration has to handle them, not flag them for manual intervention every time.

Every trading partner is their own dialect

EDI standards exist on paper. In practice, each major retailer implements them differently, with different mandatory fields, different timing requirements, different cross-reference logic. Sainsbury's AS2 implementation is not the same as Tesco's. Ocado's DESADV requirements are specific to their CFC model in ways that aren't covered in any generic specification document. Three years of building and maintaining these connections has given us operational knowledge that no amount of reading the official specs provides. That knowledge is embedded in the platform.

Businesses change more than anyone plans for

New channels get added. ERPs get switched. 3PLs change. Retailers update their EDI specifications with varying amounts of notice. Products get rebranded, warehouses move, pricing structures change. The integration that works perfectly on go-live day has to keep working through all of that. Change management — the ability to update mappings, routing logic, and configuration without rebuilding — turned out to be as important as the initial build. Maybe more so.

Visibility is not a nice-to-have

The most damaging integration failures aren't the ones that crash loudly. They're the ones that silently process wrong data — incorrect quantities, mismatched product codes, missing tracking updates — for days before anyone notices. We've invested heavily in monitoring, error surfacing, and alerting precisely because silent failures are more costly than visible ones. When something goes wrong in a Supply Lens integration, the right people know about it before the downstream consequences become a problem.

Where the platform is today

The current platform reflects all six of those lessons. It's not the architecture we're proud of — though the infrastructure is solid — it's the operational depth that's been built on top of it.

Prebuilt connector patterns
Common integration routes — Shopify to Unleashed, Unleashed to Mintsoft, retailer EDI to ERP — with all the configuration options that real deployments require.
Deep configuration layer
Warehouse routing, tax rules, customer strategy, SKU matching, channel-specific logic — handled without custom development for each customer.
50+ retail EDI trading partners
Pre-built knowledge of how major UK and Irish retailers actually implement their EDI requirements — not just what the specifications say.
Error monitoring and alerting
Proactive visibility into integration health. When something goes wrong, the right people know before it becomes a customer complaint or a chargeback.
Change management without rebuilding
New channels, new warehouses, retailer spec updates — handled through configuration, not code. The integration adapts as the business does.
Bespoke workflow extensions
Where the standard integration layer isn't enough — operational portals, data collection tools, exception queues — built around the integration rather than alongside it.

"The businesses that get the most from Supply Lens aren't the ones with the cleanest data or the simplest stack. They're the ones that were previously managing complexity manually and finally have a layer that handles it properly."

What this means for businesses evaluating integration platforms

If you're assessing integration options, the technical architecture of the platform you choose matters less than you might think. What matters is whether it can handle your specific configuration requirements, your specific trading partners, and your specific operational rules — and whether it will continue to handle them as your business changes.

The questions worth asking any integration provider are not about which cloud provider they run on or which message queue they use. They're about how they handle the specific retailers you need to trade with, what happens when a partial shipment needs to be processed, how quickly a mapping change can be made when a retailer updates their spec, and what the monitoring and alerting story looks like when something goes wrong at 2am on a bank holiday.

We're confident in our answers to those questions. Three years of building the platform around real operational requirements, rather than theoretical ones, is where that confidence comes from.

A practical starting point: Browse the integrations library to see which connectors are prebuilt, check the retail EDI partners list to see if your trading partners are covered, and if you want to understand how the platform would handle your specific setup — just get in touch. We'll tell you honestly what's standard configuration, what would need custom work, and what it would cost.

See the platform in the context of your operation

Tell us your systems, your trading partners, and where the friction is. We'll show you how Supply Lens handles it — including the parts that are genuinely complicated.