Series: Finding India (Part I of II)

The Decade-Long Journey Behind Delhivery Maps

Key takeaways:

Achieved with a remarkably lean team: A small core team of around fifteen engineers developed the Delhivery Maps platform, driven by the challenge of solving complex logistics problems.

Turning operational data into location intelligence: Instead of spending billions on traditional mapping methods, Delhivery used data generated by its own delivery network.  

Beyond the pincode: Delhivery engineers built systems like Addfix and Mapper to understand localities and route shipments correctly.

——

Building a mapping platform is one of the hardest engineering problems to solve. It requires interconnected layers of roads, localities, buildings, points of interest, metadata and algorithms - each a major engineering challenge. While most mapping companies spend billions of dollars on satellites, ground surveys and massive data collection, Delhivery built its mapping platform using the operational data generated through millions of deliveries across India. 

The result is a mapping stack designed specifically for logistics and commerce which consumer navigation platforms don’t focus on. Built over a decade with continuous learnings and iterations, the Delhivery Maps story is a ground-breaking engineering story. 

Remarkably, almost all of this was built by a team of around fifteen engineers.

“About ninety per cent of the cost has simply been people. We’ve been a relatively small team throughout. That’s probably the least number of people anyone has used to build something like this,” says Rohan Anand,  35, Vice-President & Head of Data Science at Delhivery who assembled a team of 15 engineers for the maps initiative. 

The Beginning….

When Rohan Anand joined Delhivery in 2014, the company was still in its early years. It had around a hundred employees, delivered fewer than 10,000 shipments a day, and was building the systems it needed to scale. Anand had just graduated from IIT Delhi with a degree in Mathematics and Computing and was hired as the company’s first data scientist.

Looking back, he laughs at how unusual that role seemed at the time. “Data scientists were not even a thing,” says Anand. But the opportunity appealed to him. Delhivery wasn’t asking him to optimise an existing system. It was asking him to build one. Some of his seniors from IIT had already joined the company, and they convinced him that there were enough large-scale challenging algorithmic problems in logistics.

More than a decade later, that still defines what has kept him there.

“We’re solving problems that nobody else has solved. That in itself is a huge motivator,” says Anand.

At the time, though, the team wasn’t thinking about maps. Their immediate challenge was much simpler: ensuring every parcel entered the right part of the network.

Like most logistics companies, Delhivery relied heavily on PIN codes to decide which service centre should receive a shipment. It was a sensible approach, until the company began to grow.

Customers frequently entered the wrong PIN code while placing an order. Some copied the first result they found online. Others simply guessed. India had no single authoritative directory that people consistently relied upon, and different websites often displayed different PIN codes for the same locality.

The impact went far beyond a simple data error. 

A shipment assigned to the wrong distribution centre travelled there first before someone realised the mistake. It then had to be sent back through the network, redirected to the correct facility and dispatched again. Each error added at least a day to delivery times while increasing transportation costs across the network.

When Delhivery was handling fewer than 10,000 shipments a day, these mistakes were inconvenient. As volumes grew, they threatened to become a structural problem.

The team realised that if they continued relying solely on PIN codes, the network would become increasingly inefficient as the business expanded.

Looking Beyond the Pincode

Instead of asking customers to provide better information, the engineering team asked whether they could make better use of the information customers were already giving them.

Most addresses contain clues beyond a postal code. A customer might write “Sector 44”, “Koramangala” or “Salt Lake” even if the PIN code was incorrect. The challenge was teaching a computer to recognise those clues consistently. 

The team’s first solution was Addfix, an internal system that identified the locality embedded within an address. It was followed by Mapper, which linked those localities to the appropriate Delhivery distribution centre. Distribution centres are last-mile dispatch centres which receive bulk shipments from central fulfilment centres and distribute them to delivery agents for final shipments to the consumer. 

Over time, the company built a database of nearly a million localities across India.

The improvements were significant. Routing became more accurate, misroutes reduced and the network became easier to manage.

Around the same time, the engineers began applying the same thinking to another operational challenge.

As Delhivery expanded, deciding where to open new distribution centres became increasingly important. Until then, expansion had largely been reactive. When order volumes in a city became difficult to manage, the company opened another facility nearby.

The team wondered whether those decisions could become more scientific.

They built another internal tool called Planner, which analysed where orders originated, simulated different network layouts and estimated the cost of opening facilities in different locations. One of its early successes came during network expansion in Jaipur, where the tool helped determine how operations in the city should grow.

It was an important shift in thinking. Location was no longer simply something written on a shipping label. It had become an input into almost every operational decision.

Looking back, Anand sees these tools as connected rather than independent. “Each one solved a problem we had at that stage. We weren’t trying to build maps. We were trying to make the network work better," he says. 

The Problem that Kept Coming Back

As e-commerce expanded to Tier II and Tier III towns and with the growth of low-ticket items in ecommerce, addresses became far less structured. Customers increasingly ordered from construction sites, newly developed neighborhoods, small businesses, and other temporary locations using incomplete or misspelled addresses. Delhivery’s locality database, built over the years, could no longer keep pace with this long tail of new and ambiguous locations. 

The engineers realised they were facing a different kind of problem. 

Adding more localities would improve coverage, but it would never catch up with a country where new neighbourhoods appeared constantly and existing places were known by multiple names. The more they examined the data, the clearer it became that the challenge wasn’t poor address quality.

It was the nature of Indian addresses themselves.

The solution was to move beyond locality matching and build systems that could infer a package’s approximate location even from imperfect addresses. 

The Many Ways India Describes a Place

What makes Indian addresses fundamentally different is that India has no standardized addressing system. Unlike the US or UK, where addresses follow official registries, Indian addresses are often written in whatever way people find convenient- using landmarks, local nicknames, mixed languages or informal directions that humans understand but machines struggle to interpret- “next to the fruit shop” or “take the second left.” In Kerala, for example, homes are often identified by house names rather than numbers, while villages rely on family names or nearby landmarks. 

Most mapping providers build their databases around the official form of an address. However, official addresses can be misleading. For example, Gurugram’s Institutional and residential Sector 44 share the same name but represent different locations. 

On the other hand, E-commerce platforms prioritize a seamless checkout over address validation, leaving logistics providers to interpret incomplete or inaccurate addresses. If they can’t locate the destination, the shipment is returned to the seller. 

“We realised we couldn’t simply depend on existing mapping data. We had to keep building our own understanding of locations,” says Anand. 

Learning From the Network

Around late 2017, another unexpected source of information began proving useful. Delhivery’s mobile application collected GPS data from delivery riders to calculate fuel reimbursements. The engineering team soon realised that the same data could help improve location intelligence.

But even this came with surprises.

Delivery riders didn’t always scan a shipment exactly at the customer’s doorstep. Sometimes the scan happened a few metres away. Occasionally it happened much farther away. The team responded by building systems that could validate and improve the quality of location data before it entered their models. It became another reminder that every dataset required interpretation. Every new source of information answered one question while raising another.

“The problem kept evolving. Every few years we realised we had to rethink it completely," says Anand.

The biggest breakthrough was still to come. The team would eventually stop asking where an address belonged. Instead, they would ask something no one in the team had considered before.

To be continued in Part II

(https://www.delhivery.com/blog/series-finding-india-(part-ii-of-ii)

—————

https://www.delhivery.com/maps

(Reporting and editorial by Taslima Khan)

https://www.linkedin.com/in/taslima-khan-02b22b16/