Why We Built for Multi-Stop Routes First

When we started building DeliverLoop, the first question we had to answer was what to optimize for. Point-to-point delivery tools already existed. Single-driver, single-stop dispatch was well-served. The obvious path was to start simple and add complexity later.

We did not take that path, and I want to explain why - because it shaped everything else about how the product works.

The Problem With Starting Simple

Simple routing - one driver, one destination, optimize for speed - is a navigation problem. It is solved. Every smartphone nav app does it adequately. The operations management layer on top of that is not particularly complex either. Dispatch someone, track them, confirm delivery. Done.

Multi-stop route optimization is a fundamentally different problem. When you add a second stop to a route, you have introduced a sequencing decision. When you add a third, you have a constraint satisfaction problem that grows combinatorially with every additional stop. At 15 stops with time windows, vehicle capacity constraints, and real-time traffic, you are in territory where the solution space is enormous and the difference between a good solution and a poor one is measured in hours of driver time and thousands of dollars per month.

That is where the real inefficiency in last-mile delivery lives. Not in navigating from A to B. In sequencing A through Z with constraints.

What We Learned From the LA Market

We started in Los Angeles for a specific reason. LA has characteristics that stress-test routing logic in ways that flatter geography does not. The sprawl means routes cover 20-30 miles of real distance while touching neighborhoods that look adjacent on a map but are separated by freeway-dependent travel patterns. The traffic variance between 8am and 9am on the 405 can be 30+ minutes for the same segment. The building density in certain corridors means parking and access complexity is high.

If we could build a routing engine that performed well in LA - not just navigated, but optimized across all the constraints simultaneously - it would work anywhere. LA was the hardest version of the problem we could find that was still within driving distance of our office.

The first prototype we tested in the field used a modified nearest-neighbor heuristic with time-window constraints. It was fast. It was also consistently 12-18% worse than optimal on total route distance and frequently violated time windows on the back half of routes. Operators using it in the field noticed immediately. Route sequences that looked clean on a map were producing late deliveries and frustrated drivers by noon.

The Engine We Actually Built

The routing engine that ships in DeliverLoop today uses a hybrid approach: constraint-based initial sequencing combined with local search optimization that runs continuously until dispatch time. It factors in hard constraints (time windows the customer has specified, vehicle capacity, driver hours-of-service) and soft constraints (preferred delivery times, customer tier, historical stop duration data).

The stop duration data was a specific insight we developed in LA. Generic routing tools estimate stop duration uniformly - often 2-3 minutes per stop. In practice, stop duration varies enormously. A residential doorstep delivery with safe placement takes 90 seconds. A business delivery requiring signature verification and loading dock access takes 8-12 minutes. An apartment complex with a difficult intercom system takes 4-6 minutes on average. The first time a driver visits a new address, they take longer. The fifth time, they have it figured out.

Building historical stop duration data into the sequence optimization changed our time window compliance rates meaningfully. When the model knows that address 4521 West Third Street typically takes 7 minutes because it is a busy restaurant supply company with a staffed receiving department, it allocates that time in the sequence rather than assuming a standard 3 minutes and blowing the downstream schedule.

Why Multi-Stop First Matters for Single-Driver Operations

Here is the thing: starting with multi-stop complexity made us better at simple dispatch too. The constraint-satisfaction machinery that handles 28-stop routes with time windows handles 8-stop routes easily and with more sophistication than tools that were built for simple use cases and tried to scale up. Single-vehicle operations benefit from the same sequencing quality, historical stop data, and real-time adjustment logic as large fleets - they just use it on smaller routes.

We have customers running 6-vehicle operations who use features built to handle 50-vehicle fleets. The complexity of the problem is in the per-route optimization, not in the fleet size. A 6-vehicle operation doing 180 stops per day has exactly the same sequencing challenge as a 50-vehicle operation - just 8.3x more of it.

What This Means for Operators Evaluating Routing Tools

When you are evaluating routing software, ask the vendor what their system was designed to optimize first. Tools built for point-to-point dispatch that added multi-stop as a feature typically perform well on simple cases and degrade on complex ones - many stops, tight windows, mixed vehicle types, real-time disruptions. Tools built for multi-stop complexity from the start tend to handle simple cases fine and hard cases much better.

The test is not a demo on clean data with 15 stops. The test is your worst Tuesday in December with 34 stops, a driver who called in sick, three address changes, and a customer who moved the window at 9am. That is when the architecture choice matters.