The challenge
Routing decisions were spread across six vendors: one for geocoding, two for traffic, one for demand forecasting, and two more for the optimisation itself. Each had its own SLA, its own failure mode, and its own idea of what a shipment looked like.
The glue between them was a Python service nobody on the current team had written. It carried no tests, and a single vendor timeout could stall dispatch for an entire region. Adding a fourth region had been on the roadmap for two years.
What we did
We started by drawing the actual data flow rather than the one on the architecture diagram, and found four places where the same shipment was being re-geocoded within a single request.
The replacement is one inference API in front of a routing model we serve ourselves, with the vendor calls that genuinely add value reduced to enrichment steps behind a cache. Everything else was deleted.
Rollout ran region by region behind a traffic split, with the old pipeline kept warm for a full quarter so any regression could be reversed in minutes rather than days.
Where it landed
Dispatch now runs on a single API with one SLA and one owner. The fourth region went live eleven weeks after the third, against a two-year stall on the old stack.
Cost fell mostly by deleting redundant vendor calls rather than by negotiating rates — the same journey had been paid for four times.
Something similar on your side? Tell us the shape of it.