Location features fail in India for a reason that has nothing to do with the mapping library. Addresses here are frequently descriptive rather than structured — a landmark, a lane, a building name that the postal system recognises and no geocoder does. A pin dropped by the user is often more reliable than the text they typed.
Design for the pin. Capture coordinates at the point of address entry, store them alongside the text, and treat the text as a delivery instruction for a human rather than as the machine-readable truth. Every serviceability calculation should run on the coordinates.
Serviceability itself is a geometry problem. A delivery zone drawn as a polygon and tested with a point-in-polygon query is straightforward, well supported by PostGIS, and fast enough with a spatial index. Zones defined as lists of PIN codes are easier to explain to operations teams and consistently wrong at boundaries, because PIN code areas are large and irregular.
Distance needs care. Straight-line distance is cheap and misleading in a city with rivers, flyovers and one-way systems. Road distance requires a routing service and costs money per call, so cache aggressively — the distance between a warehouse and a customer does not change between orders.
Storage matters more than people expect. Use a geography type rather than storing latitude and longitude as two floats, and index it. The difference between a spatial index and a full scan on a table of a few hundred thousand locations is the difference between a responsive app and a timeout.
Finally, decide early whether you need offline map tiles. Field service and logistics apps in India routinely operate where connectivity does not, and retrofitting offline support into a mapping feature built for the browser is close to a rewrite.
