This article was written by Brîndușa Niculae, Engineering Manager at Bolt.

In an app that connects three parties — the customer, the merchant, and the courier — time efficiency is essential. For customers, we need to ensure that meals arrive at the correct address and on time. For couriers, we need to ensure that they spend their time in the app efficiently — on the move, taking the best route, picking up orders, and finding delivery addresses seamlessly. For merchants, this means ensuring the food is ready when the courier arrives to collect it.

Given the volumes of orders processed by Bolt Food each month across hundreds of markets, even slight inaccuracies at the address or routing layer can lead to significant inefficiencies. Solving these challenges at scale requires robust engineering, precise data, and reliable geo-intelligence.

At Bolt, several teams work on ensuring the proper orchestration between the 3 parties. One of the teams involved is Geo, where I work, which is responsible for providing the correct geographical data, including routes, ETAs, addresses, and coordinates.

There are several foundational engineering challenges that we needed to overcome to improve delivery address detection and routing reliability:

Reverse geocoding fuzziness → non-deterministic address results
GPS drift and multipath interference → unstable current location signals
Pin placement inaccuracies → mismatched driving and walking routes
Snap-to-road routing behaviour → route endpoints that don’t match building entrances
Unstructured or inconsistent address metadata → limited guidance for couriers
Cold-start problem in new buildings or developing areas → insufficient historical data for accurate entrance prediction

These challenges impact the delivery experience in two major areas: how the app determines the delivery address, and how couriers reach the customer during the last mile. In this article, I’ll walk through both.

Making the default delivery address smarter

This is a high-frequency flow: every customer relies on this moment to start their order. Across our markets, this translates into thousands of address requests every day, meaning the accuracy and speed of this step have a direct impact at scale.

When the customer opens the Bolt Food app, the geosystem receives 2 API calls: one to determine the delivery address and another to assess their current address based on their current location via reverse geocoding.

Reverse geocoding is the process of converting geographic coordinates (latitude and longitude) into a human-readable address or place name. For example, latitude 44.428 and longitude 26.035 correspond to a shopping mall in Bucharest, Romania, located at the address "Bulevardul Timișoara 26".

In the initial state, the delivery address was the last address the user ordered to. If the delivery address and the current address are far apart, we display a banner that nudges users to check their delivery address. The delivery address is displayed at the top of the screen and also in the middle of the banner (“Bulevardul Timisoara 16B”). The current address is the first one in the banner (“Splaiul Unirii 165”).

Technical constraints in address selection

Automatically setting the delivery address to the last one used in an order was not ideal for cases when users change their location from one order to the next. Say, they ordered yesterday’s dinner home and today’s lunch to the office.

Not all users would notice the incorrect address (or the banner), and they would place orders to their home address instead of the office. This, in turn, would lead to increased customer support tickets, couriers heading in the wrong direction, food arriving late, cold, or, worst of all, not at all.

Another drawback is that updating the address requires additional actions from the customer, thus delaying the order placement.

Determining the current address is also error-prone because it relies on fuzzy functionality.

Reverse geocode is fuzzy. This is because it retrieves the nearest address available. Pins placed on and around buildings may mean different addresses. For example, latitude 44.44475 and longitude 26.054678 mean "Splaiul Independenței 290C" (the first image below). Moving the pin in front of the building, on the road, at latitude 44.444495 and longitude 26.054716, would change the address to "Splaiul Independenței 305" (the second image below).

The current location ( the coordinates used as input for reverse geocoding) can also be incorrect due to GPS jumps. This behaviour can occur due to signal interference or low satellite visibility. Typical causes include being near tall buildings, having insufficient satellite reception, turning location services off, or enabling low power mode on a device.

Taking these drawbacks and technical constraints into account, we set out to improve the automatic setting of the delivery address at app startup to the most likely address the customer will order to.

Solution

To address the drawbacks, we decided to leverage more of the customers' delivery history than just their most recent order. The idea is simple — check if a person has orders around their current location instead of using the address of the last delivery. If they do, use that address instead. We took this solution a step further by applying it not only to the delivery address but also to other relevant areas. We decided to apply it to the current address as well (e.g. instead of using only reverse geocode). With this solution, we bypass the fuzziness of reverse geocode. We have confidence that the resulting address is correct because the user has successfully placed orders at that location in the past.

This approach also makes address selection deterministic instead of probabilistic. Rather than relying on a fuzzy reverse-geocode result that may return different addresses depending on pin placement, we use real behavioural signals from past successful orders. This gives us a far more stable and trustworthy input for the delivery pipeline.

On the technical side, this solution was made possible due to the use of Elasticsearch (ES). It allows combining geospatial filters with full-text search to retrieve results. Since the delivery address is set at app startup, efficiency is crucial, and ES enables fast, real-time search.

Although exact numbers vary by market, after rollout, we observed a significant reduction in support tickets related to incorrect delivery addresses.

Solving the address selection accuracy removed one of the biggest sources of friction. The next major bottleneck appeared in the last mile, where couriers rely on our routing engine and user-inputted address details to complete the delivery.

Applying geo-intelligence to improve the last mile of delivery

This part of the journey depends on how well our system guides couriers as they drive, park, and walk to the customer’s door — all of which rely heavily on routing behaviour, pin placement, and the quality of address details.

Let’s say the customer has the correct address and placed the order. The courier is now en route to deliver the food. An important particularity of food delivery is that to complete it successfully, a courier needs to drive their vehicle, park it, and then walk to the door of the customer. To cover these steps, we rely on two mechanisms: a call to the geo system to obtain the drivable route (which uses the customer's pin as the ending location) and the address details added by the customer to guide couriers through the walking segment. Initially, the address details consisted of two fields, as shown in the image below:

Ideally, the delivery leg should look like this:

Technical constraints in the last mile

A technical constraint arises when attempting to retrieve the drivable route from the courier's location to the customer’s pin. Since this pin can sometimes be placed in the middle of a building, and the geo route only covers the driving segment, the system needs to snap it to a drivable road first.

Due to the snapping, even though two users have the same delivery address, but different pin positions, the walking segment might differ. In the images below, it can be seen that, depending on the position of the blue pin on the building, the snapped pin (in yellow) is on a different street. If the entrance to the building is on the southern street, then for cases when the drivable route ends on the northern street, the courier needs to walk further to reach the entrance once they figure out where it is.

Another drawback is the limited information couriers have for the walking segment. They have access to the customer’s pin and address details. If the information provided in these is insufficient, couriers would contact the customer via call or chat for guidance, thus further increasing the inefficiency of the delivery.

In reality, the delivery leg looks like this:

Taking this into account, we set out to increase the efficiency of the delivery by guiding the courier to a more reliable pin and improving the information provided by customers.

Solution

The first thing we needed to determine was a more reliable pin. Since our end goal is to have the delivery efficient and effortless, in an ideal case, the courier would drive their vehicle until the entrance of the building, park, and then walk the minimum distance to the customer’s door. For them to get to the building entrance, the route needs to end there, meaning the snapped location needs to be on the road closest to the building entrance. With this in mind, we decided that the most reliable pin is the one placed on the entrance of the building.

The next thing we needed to decide was how to approach this. It’s the customer who provides the pin, but asking them to update it to the building entrance would take time, so we decided to build a system that automatically detects the building entrance, starting from the already available customer pins.

Because Bolt Food operates in cities with different building styles, street layouts, and address conventions, the system needs to generalise well across highly diverse environments. A scalable, data-driven approach was essential — manual tuning for each city is simply not feasible given our scale.

The solution was to build a model that aggregates historical geospatial data of orders, along with building footprints, and learns where the most likely entrance is. We then propagated the learned information back to both couriers and customers to ensure a smooth transition. In the following image, the detected entrance is the largest red marker.

Since the data science solution requires orders first, so that the model can have something to learn from, we needed a complementary solution to cover areas without order history (e.g. launching the food app in a new city, building a new residential area etc), To address this, an informative tooltip was added in the app to guide customers to place pins on the building entrances.

Additionally, to encourage customers to provide as much helpful information as possible to the couriers, the two fields of address details were split into several specialised fields. Having a standard format for the data would make it easier to read and interpret. With the initial state of two fields, formatting could vary. With the introduction of the detailed form, the format is standardised.

Conclusion

Having these solutions in place proved to be highly effective in improving the efficiency of the delivery leg. By streamlining processes, optimising route planning, and leveraging real-time data insights, we have successfully addressed historical bottlenecks and friction points within the delivery network.

At Bolt’s scale, even marginal improvements in routing or address accuracy translate into thousands of successful first-attempt deliveries every day — directly improving courier efficiency, customer satisfaction, and operational reliability.

The suite of deployed solutions has transformed the delivery leg from a potential source of operational friction into a highly efficient, predictable, and scalable component of the overall service, directly contributing to higher customer satisfaction and lower operational expenditure.

Join us!

Grow fast, make a global impact, and help make cities for people, not cars. Explore hundreds of open roles on our careers page.

How Bolt engineers improve delivery address accuracy to reduce failed orders and "Where are you?" calls

We’re hiring!

Recent posts

How Bolt’s Warsaw hub powers global innovation