Last-mile logistics software built on assumptions that hold in Europe or North America performs badly in India, and the reasons are not about algorithm quality. They are about the inputs: addresses that do not geocode, roads that are not passable at the width the map assumes, recipients who are not where the address says, and a delivery model where cash frequently changes hands at the door.
Address resolution is the first and largest problem. A substantial share of Indian addresses are relational rather than absolute — a building name, a floor, a landmark, an area — and geocoding them produces a point that may be several hundred metres out or in the wrong locality entirely. Systems that route purely on geocoded coordinates send riders to the wrong place, and the rider then phones the customer, which is the workaround the whole system was meant to remove. Capturing and using the landmark, and letting riders correct and save a resolved location for future deliveries, is worth more than any routing improvement.
That correction loop is the highest-return feature in this category. Every successful delivery is an opportunity to record where the address actually is, from the rider's own position at the point of handover. Over months this builds a private map of verified locations that no commercial geocoder has, and it compounds — repeat deliveries to the same address stop being a navigation problem at all.
Routing has to account for constraints that maps do not encode. Vehicle type determines which lanes and gullies are passable, and a route optimal for a car is impossible for a truck and irrelevant for a two-wheeler. Time-of-day restrictions apply to commercial vehicles in many cities. Traffic is not a modest adjustment to travel time but the dominant term. And building access — a gated community requiring registration, an office with a goods entrance on another road — is knowledge that lives with experienced riders and should be captured in the system rather than in their heads.
Cash on delivery changes the software's obligations. The rider is carrying money, which means reconciliation between what was collected, what was recorded and what was deposited is a daily operational process with real financial consequences, not a reporting nicety. It also changes the failure modes: refused deliveries, partial acceptance, and orders placed with no intention of paying are logistics costs the software has to make visible.
Finally, design for the rider as the primary user, not the operations dashboard. The application runs on a mid-range phone, in sunlight, on a moving vehicle, often with one hand, in an area with patchy data. That means large touch targets, offline capability with queued updates, minimal typing, and a proof-of-delivery flow that works when the network does not. Software that riders find slow gets worked around, and once that happens the data in your beautiful dashboard is describing something that did not happen.
