Grocery delivery is a route optimization problem that looks like every other route optimization problem until you actually try to run it. Then it becomes the hardest one in the building.
Most route-optimization tools were built for the easy case. Drop a hundred parcels in a city, find a good route, done. Grocery delivery is not the easy case. The constraint density that gets you to a one-hour window for ice cream is the part the engine has to absorb, and it is the part the lightweight tools quietly ignore.
This post walks through what running grocery delivery at national-retail scale actually requires, using the operation Mycelium runs for Shufersal in continuous production since 2016. 18M+ delivery routes since 2016. 230M+ individual orders. Branches with different vehicles, different rules, different operational shapes. All of it on a single optimization API that responds in seconds. For the data-driven version of this story with the integration timeline and architecture diagrams, see the national grocery retail case study.
The Operation. Shufersal Since 2016
Shufersal, established 1958, operates supermarkets, discount stores, neighborhood grocery, and an online supermarket that grew from a side bet into a national delivery channel. As e-commerce volume climbed, Shufersal’s last-mile operation hit the wall every national retailer hits at some point. Volume scaled. The previous routing tool didn’t.
Mycelium took the account in 2016 after several months of joint review of internal systems and workflow. The deployment that came out of that work has been running ever since. Each branch sends its open delivery roster to the API. The API returns optimized routes in seconds. Drivers get the plan. The customer gets the window. Repeat thousands of times an hour, every hour.
Two facts from that deployment matter more than the volume number. First, delivery windows compressed from five hours to two hours for the end consumer inside the first two years of production. Window length is the only number a customer choosing where to buy ice cream actually cares about. Second, the operation now ships millions of items per month, item sizes from 100 grams to 50 kilos, anything from frozen produce to large appliances, dispatched across both Shufersal’s own fleet and external contractors. The platform decides the split per request.
What the Engine Has to Hold
Generic route optimization assumes a homogeneous fleet, a single depot, and a customer who is happy to receive the package whenever the truck shows up. Grocery breaks all three assumptions on day one.
- Per-branch fleet heterogeneity. Refrigerated vans for chilled, larger trucks for bulky items, lighter vehicles for dense urban runs. The branch network is not one fleet, it is a federation of fleets.
- Per-branch optimization rules supplied per request. The API accepts a fresh rule set on each call. A branch can change its operational policy on a Tuesday afternoon and the next request reflects it without a deploy.
- Temperature constraints across frozen, refrigerated, and ambient categories that affect both vehicle assignment and route sequencing.
- Customer-chosen time windows that have to be honored against the realities of city driving and stop service times.
- Multi-carrier dispatch across owned fleet and external contractors with different cost models, capacities, and service-level commitments.
- Same-day re-optimization on top of the morning batch when a high-priority order arrives mid-shift, without scrapping the in-flight plan.
- Plan-versus-actual tracking that survives the day-after audit, so the operation knows which routes paid for themselves and which leaked.
Each of those is a constraint dimension. Hold all of them at once and the problem is no longer a textbook VRPTW. It is a planning problem the routing tool either models honestly or routes around by pretending the constraints don’t exist. For a deeper look at how the underlying optimization works, see the complete guide to route optimization.
The Two Shapes of Grocery Delivery
Operators who say “grocery delivery” usually mean one of two distinct things, and the optimization engine has to know the difference.
The first shape is scheduled batch delivery. The customer picks a window when they place the order. The branch builds the day’s routes once or twice, optimizes against the full set of orders, and dispatches drivers on a known plan. This is the bulk of the volume at most national chains. It is the Shufersal case above.
The second shape is on-demand short-window delivery. The customer expects the order in two hours, sometimes one. The depot does not get to plan once and dispatch. It has to combine the new order with whatever is already in motion, decide whether to re-route a courier, and push the change to the driver in seconds. Express grocery, dark-store delivery, and same-day pharma all run on this shape. An online pharmacy operator runs on Mycelium with two parallel models, an immediate two-hour delivery and a same-evening window. Before that deployment, couriers ran one delivery per trip. After, up to five per trip via order combining by location and time window. The online pharmacy case study covers the mechanics. The optimization rules differ from scheduled batch. The platform does not.
This distinction is the hidden cost in most platform-selection decisions. A platform that runs only the first shape is a route optimization tool. A platform that runs both is a dispatch system. The retailer who wants to roll out an express grocery line on top of an existing scheduled delivery operation needs the second. For the broader category map see our dispatch automation platforms comparison and route optimization platforms comparison.
What Buyers Don’t Realize
The interesting part of the Shufersal deployment is not the cost reduction or the seconds-fast response time. Both are real and both are table stakes for any modern routing engine. The interesting part is what is in the constraint library after a decade.
Mycelium has been adding constraints to the grocery model since 2016. New vehicle types as the chain rolled out new branch formats. New per-branch rules as operations leadership tried different last-mile strategies. New carriers and new cost rules every time the contractor mix shifted. None of that is a feature flag. It is constraint code, written once, available to every other operation on the platform afterward. Grocery, pharma, parcel, field service, crew transport: nine verticals running on Mycelium today, and every new vertical adds back into the shared library that compounds across all of them.
This is the part that matters when you compare Mycelium to a freshly funded routing API. The solver is a commodity. There are excellent open-source ones. The constraint library is not. There is no shortcut to the years of edge cases that get a national grocery operation from default delivery windows down to the tighter ones the customer actually wants. A new entrant can launch a clean routing API tomorrow. They cannot launch a constraint library that has already absorbed a decade of national retail.
The largest grocery deployment on the platform is Shufersal’s, in production since 2016. Enterprise retailers do not keep an optimization API in production for a decade by accident.
When a Lightweight Tool Is Still the Right Answer
Not every grocery operation needs Mycelium. A single-branch organic delivery service planning forty stops a day on one type of vehicle, with no temperature splits and no contractor mix, is solved by a lightweight routing app and a competent driver. Below roughly 200 stops per day, a single distribution center, one fleet shape, the marginal value of a constraint engine is small enough that the operational simplicity of a lighter tool wins.
The crossover happens at one of three points. Multi-branch operations where each branch needs different rules. A meaningful fraction of orders arriving same-day where re-optimization actually matters. Or a contractor mix where the platform has to decide the split between owned and outsourced delivery per order. Hit any of those three and the lightweight tool starts losing money the operator cannot see in any single day but absolutely sees on the quarter.
What to Look For in a Grocery Delivery Optimization Platform
If you are evaluating route optimization for a grocery operation that has crossed the threshold above, the things that actually matter, in priority order.
- API-first architecture with per-branch and per-request rule injection. Operations should be able to change a rule without waiting on a release cycle.
- Real multi-carrier orchestration. Own fleet plus contractors plus on-demand fleets, decided per order against cost and service-level rules, not bolted on as an export to a separate dispatch tool. See the multi-carrier orchestration page for the architectural picture.
- Temperature, vehicle-type, and load constraints modeled natively. If the platform’s docs treat “refrigerated” as a metadata tag instead of a routing constraint, walk.
- Sub-seconds-to-seconds response time at thousands of requests per hour per branch. Grocery operations replan constantly. A platform that takes a minute to return a plan is a platform that runs the morning batch and nothing else.
- Same-day re-optimization that does not scrap the in-flight plan. Drivers should not be re-sequenced halfway through a route just because one new order came in.
- Plan-versus-actual analytics that survive the day-after audit. The operation needs to know which constraints bind in practice, not just which ones bind in theory.
- Production deployments at national-retail scale, ideally measured in years rather than months. The constraint library is the moat. Tenure is the only proof it exists.
Last-mile delivery generally is covered in our last-mile delivery optimization post, and the last-mile delivery solutions page goes deeper into the operational scenarios Mycelium handles. The fleet-management-software perspective on the same operation is in our enterprise fleet management software comparison.