A ride-hailing startup was launching with a manual dispatch process that couldn't scale past a handful of drivers. DXDasia built a full rider and driver app with real-time matching, cutting matching time 3× and cancellations 28%.
3× Faster Driver-Rider Matching, 28% Fewer Cancellations
The startup had validated demand with a manual, phone-and-spreadsheet dispatch process, but it was already breaking down at a small scale — the exact point where the business needed to prove it could grow.
We built a rider app and a separate driver app sharing one real-time backend, replacing manual dispatch with automatic, location-aware matching.
Replacing manual dispatch with automated, real-time matching changed both the speed and the reliability of every ride:
Ride-hailing lives or dies on the few seconds between a booking and a confirmed match — every extra second of uncertainty is a rider who cancels and books a competitor instead. Automating matching, tracking, and payment removed manual delay from every single step of that critical window, not just the slowest one.
The matching engine uses geospatial queries (PostGIS on top of PostgreSQL) to find the nearest available drivers in real time, rather than scanning the full driver list on every request. Live location updates flow over WebSocket connections rather than polling, keeping both the rider’s tracking view and the matching engine’s driver-availability data current within seconds. Redis caches active driver locations in memory for fast lookups, since matching speed depends on not hitting the primary database for every location ping. Payments integrate directly with the gateway’s mobile SDK rather than a web redirect, keeping the whole booking-to-payment flow inside the app.
Tech Stack: React Native for rider and driver apps, Node.js backend, PostgreSQL with PostGIS for geospatial matching, Redis for real-time location caching, WebSocket for live tracking, Google Maps Platform for routing and ETAs, Stripe for in-app payments.
Matching speed is a geospatial problem before it is anything else. Uber describes H3, its open-source hexagonal grid, as built for "efficiently optimizing ride pricing and dispatch". A latitude and longitude pair becomes a 64-bit cell index at a chosen resolution (0 to 15), and a kRing call returns every cell within a set grid distance of an origin, which is how you shortlist nearby drivers without scanning all of them. The same post notes that a hexagon has one distance to each neighbour, where squares have two, which simplifies smoothing.
If you stay inside PostgreSQL, the PostGIS documentation says the <-> operator can use a 2D GiST index for nearest-neighbour ordering, but only in an ORDER BY clause and only when one geometry is a constant. A query written any other way can quietly fall back to a slow scan, so test the query plan, not just the result.
India's Motor Vehicle Aggregator Guidelines 2025, as reported by Entrackr on 2 July 2025, allow surge pricing up to 2x the base fare and off-peak discounts of up to 50%. They also set a cancellation penalty of 10% of the fare, capped at Rs 100, for drivers or passengers who cancel without a valid reason. Drivers using their own vehicles get at least 80% of the fare, and 60% where the aggregator owns the vehicle. States set base fares and decide how to adopt the guidelines, so treat these values as configuration, not code.
Android's developer guidance says most use cases only need location while the user is engaging with the app, and that Google Play restricts background location to apps that need it for core functionality. Apps running in the background on Android 8.0 and later receive updates only a few times each hour. A driver app that must share position during a trip is the legitimate case. A rider app usually is not.
| Design decision | What the source says | Implication |
|---|---|---|
| Nearest-driver lookup | H3 cells and kRing, or a PostGIS GiST index used through ORDER BY (Uber, PostGIS) | Index the lookup and verify the plan |
| Surge pricing | Up to 2x base fare, off-peak discounts up to 50% (Entrackr) | Make the multiplier cap a setting |
| Cancellation fee | 10% of fare, maximum Rs 100, only without valid reason (Entrackr) | Record a reason code for every cancellation |
| Driver payout | At least 80% (own vehicle) or 60% (aggregator-owned) (Entrackr) | Show the split on every receipt |
| Background location | Only where core to the app (Android) | Request it in the driver app only |
Design decisions for a ride-hailing build and the published rules behind them. India figures are from press reporting of the 2025 guidelines.
Whether you run a taxi fleet, a delivery service or a field-service team, the same sequence keeps a dispatch product honest.
With the core matching and tracking infrastructure proven at current volume, the platform is built to scale by adding server capacity rather than rethinking the architecture — the geospatial matching approach doesn’t degrade the way a manual or naive full-table-scan approach would as the driver base grows. The trip and location data being captured is also opening up a driver-incentive program based on actual coverage gaps by area and time of day, something that was impossible to see clearly under the old phone-based dispatch process.
For an early-stage fleet, a spatial index in your main database is usually enough and keeps the stack simple. A grid system such as H3 becomes attractive when you also need to aggregate demand by area for pricing or incentives, because cells give you a ready-made unit to count and smooth.
Press reports of the 2025 central guidelines describe a cap of 2x the base fare, with states setting base fares and adopting the rules. State drafts and notifications can differ, so check the rules for each state you operate in and keep the cap configurable.
Android's guidance says most use cases only need location while the user is in the app, and Google Play limits background location to core functionality. Asking for more than you need can delay approval and put users off. Track drivers during trips, and riders only while the app is open.
Both are used for live-tracking apps. React Native's New Architecture has been the default since version 0.76 in October 2024, and its team declared it ready for production use. Decide on your team's skills, the device features you need and how much platform-specific polish matters, then test on low-end phones.
It depends on scope: two apps, an admin panel, payments, maps usage and regulatory features all move the figure. Our guide on what drives mobile app development cost explains the variables, and a written quote follows a discovery call.
