How the Middle East’s Leading Super-App Achieves Precision ETAs With Captain-Behavior-Aware Routing

AT A GLANCE

• Multi-country delivery operations across the Middle East
• Marketplace platform powering food, grocery, and on-demand delivery
• Mixed captain fleet: motorized, e-bike, and walking couriers
• Evaluating Distance Matrix, Directions API, and Navigation SDK

BACKGROUND

This organization operates one of the most widely used super-app platforms in the Middle East, with a marketplace layer that powers food delivery, grocery, and a broad range of on-demand services. Its delivery operations span multiple countries and captain types — from motorized couriers to e-bike and walking captains in dense urban zones like Dubai.

At the heart of its operations is a routing and ETA engine the company had built in-house, running on OpenStreetMap data and its own historical fleet data. While functional, the system had limitations in traffic accuracy, ETA precision, and scalability — and the team was actively evaluating whether a specialized routing infrastructure provider could improve performance and reduce costs.

THE CHALLENGE

The company’s in-house routing system produced ETAs that did not always reflect real-world captain behavior. A key structural reason: captains are paid on distance, not time. This means a captain choosing between a three-kilometer and a four-kilometer route will typically take the longer one — not because it’s faster, but because it pays more. A routing engine that only returns the theoretically fastest or shortest route therefore produces ETAs that are systematically off from what actually happens on the ground.

Beyond the captain-behavior problem, the team identified several other friction points that were driving the evaluation:

Key Pain Points

• In-house routing built on OSM lacked the real-time traffic fidelity needed for accurate ETAs across a high-density, high-frequency delivery operation
• No reliable mechanism to incorporate captain route preferences into ETA predictions — the system assumed optimal behavior that captains didn’t always follow
• Drivers using Google Maps or Waze for turn-by-turn navigation, which was not integrated into the company’s own driver app — creating a disconnect between planned and actual routes
• Distance Matrix constraints at scale: The incumbent API supports a 25×25 matrix per call, requiring many sequential calls for large-scale origin-destination calculations
• No support for e-bike or pedestrian routing profiles needed for walking captains and e-bike couriers in Dubai
• No ability to query historical ETAs for past timestamps — limiting the team’s ability to build robust benchmarking and model validation pipelines

Why the Existing Stack Fell Short

• OSM-based routing without high-quality real-time traffic data produced ETAs with inaccuracies at peak hours
• No structured feedback loop to adapt routing recommendations based on observed captain behavior over time
• 25×25 Distance Matrix ceiling required expensive API call multiplication for large fleet operations
• No in-app navigation SDK created a loss of routing control and data visibility
• Inability to query time-of-day or historical ETAs limited the quality of analytical models being built by the data science team

THE NEXTBILLION.AI SOLUTION

Distance Matrix API

• Supports up to 5,000 x 5,000 origin-destination pairs in a single API call, dramatically reducing the number of API calls required for fleet-scale ETA calculations and associated costs
• All ETAs returned are traffic-aware by default, using real-time traffic data
• Custom departure time supported for both future and historical timestamps — enabling the data science team to query what ETAs would have been at any point in time, which is critical for model validation and benchmarking
• Historical traffic modeled in 15-minute time buckets per day, with speed profiles matched to the specific departure time provided

Directions API

• Returns route polyline, ETA, and total distance for point-to-point routing — giving the data science team the actual predicted route, not just a duration estimate
• Alternate routes option returns multiple route options sorted by distance, enabling the team to identify which route a distance-incentivized captain is most likely to take and calibrate ETA models accordingly
• Waypoint support for multi-stop routing within the same call
• Flexible API option accepts Unix timestamps for historical and future departure times — consistent with Distance Matrix API structure

Navigation SDK

• Fully embeddable within the company’s existing driver app — no separate navigation application required
• Converts planned routes directly into turn-by-turn instructions displayed in-app, alongside other widgets such as new order notifications and booking offers
• Addresses the current disconnect between planned routes and actual navigation, enabling route enforcement and closing the feedback loop on actual vs. predicted paths

E-Bike and Walking Routing

• Custom routing profiles for e-bike and pedestrian captains
• Requires a calibration period using the company’s local fleet data to tune speed profiles and route preferences for the Dubai market specifically

Data Infrastructure

• Multi-source data ingestion: OSM, TomTom real-time traffic, historical traffic, incident data, and the company’s own historical fleet data
• Data-agnostic architecture allows the company’s existing historical captain track data to be ingested and used to inform routing recommendations
• Custom map editing capability: road restrictions, custom rules, and geography-specific constraints can be applied