Shared Ride Matching for Taxi Dispatch Software: An Uber Pool-Style MVP in 10 Weeks
Industry: Ride-hailing / urban mobility
Project type: Ride hailing software MVP — shared ride matching, driver app and dispatch logic
Context
A large ride-hailing platform wanted to launch shared rides: several passengers going the same way share one car and one driver. This is a direct analog of Uber Pool. Public reports on Uber Pool showed it ran with negative unit economics and was justified mainly by retention. The goal here was different: launch shared rides and make the unit economics positive.
The mechanics are simple. During peak demand, a rider ordering from a busy area gets an offer to share the trip. They either take the first seat and someone joins on the way, or they join a car that is already on a trip. In exchange they get a discount of up to 30% off the surge price. The trip can take up to 30% longer, but the rider is sure to get a car, pays less, and sometimes meets someone new along the way.
The Problem: Low Driver Utilization and Lost Riders in Taxi Dispatch
Every taxi dispatch system fights two problems.
Driver utilization. A driver has a fixed number of hours on the line. Time and distance between the end of one trip and the start of the next — empty runs to the next pickup — are poorly paid. The platform wants a driver carrying a passenger as much of the day as possible.
Lost demand at surge. When demand spikes, the price goes up. Some riders drop off because they won't pay that much. That hurts retention: a rider who could not get a car last time, or found it too expensive, is less likely to come back. Riders return when they actually got where they needed to go.
Shared rides attack both at once: one car serves more orders, and riders who would leave at the surge price stay at a discount.
The economics are tight. If each of two matched riders gets about a 20% discount, the platform needs roughly 70% of shared-ride orders to actually match just to break even. Unmatched riders still get the discount, and the driver still gets the full fare, so the platform pays the difference out of its commission. Two earlier attempts at this product had taken about six months each and had failed.
The Solution
Matching Logic on Top of the Existing Dispatch
The platform's dispatch does not assign the nearest driver. The map is split into small zones. In each zone, orders are buffered for about ten seconds, then matched against all drivers who can reach the zone within a few minutes, including drivers about to finish a trip nearby. The algorithm optimizes for the whole group: low average pickup time and no outliers where most riders wait two minutes and one waits fifteen.
Shared ride matching was built on top of this. From the regular economy orders, the algorithm picks candidates for a first trip:
- a minimum trip length of about 8 km — short trips almost never match;
- longer trips are preferred: the longer the route, the higher the chance to pick someone up along the way;
- trips from the center toward the outskirts at peak hours are the best candidates, because that is where directional flow is densest.
While the driver is on the first trip, the system keeps looking for a second order on the way. A match is allowed only if the first passenger's trip time and distance grow by no more than about 30%. If no match is found, the rider simply rides alone at the discounted price.
Nested vs. Sequential Matches
There are only two ways two trips can overlap:
- Nested: pick up A, pick up B, drop off B, drop off A.
- Sequential: pick up A, pick up B, drop off A, drop off B.
The hypothesis for the MVP was that nested matches alone would reach an acceptable match rate. Nested matches are rarer, but much cheaper to build. If they worked, that would prove the product and justify building sequential matches next.
A Driver App Workaround Instead of a New Release
The driver app could handle only one order at a time. Shipping a new version to every driver takes months: release, store review, waiting for drivers to update. For a fast test, the team built a "nested order" scheme on the backend:
- The driver picks up the first passenger.
- When a second passenger is matched, the backend tells the driver app to forget the first order. It disappears from the screen.
- The second order is pushed to the driver. The driver picks up, drives and drops off the second passenger as a normal trip.
- After that trip ends, the backend returns the first order to the screen, and the driver finishes it.
The backend kept the real state: which driver has how many orders and in what status. The switching logic lived on the backend too. To store the link between orders, the team reused an existing optional metadata field in the order structure instead of changing the data model.
The client app needed much less work: a new tariff built from an existing template, with its own name and description.
Why the Microservice Architecture Mattered
Earlier attempts ran on a single large monolith that held the whole order cycle, reviews and everything else. After a major outage, the platform split it into microservices and made the core order cycle — order, dispatch, trip, completion — the most stable part. Discounts, ratings, support and order history can fail without stopping a ride. For this project, that meant the team knew exactly which services needed changes, instead of digging through one huge codebase.
Driver Onboarding and Testing
You cannot gather all drivers in a room. The team turned the feature on for economy drivers in one city, added a light onboarding of a few screens, and then collected feedback:
- product managers called drivers who had just done shared trips, after checking they were off shift, and asked what was clear and what was not;
- loyal drivers were invited to the office for UX testing on prototypes;
- the product lead drove with the app himself, because a driver only glances at the screen for a second or two and the interface has to read instantly;
- before release, developers and the product lead placed 30–40 test orders over half a day from several phones.
Results
- Built in 2.5 months, from idea to release — the two earlier attempts took about six months each and failed.
- About 30% match rate on the nested-only MVP.
- With sequential matches added, the projected match rate was 60–70%, around break-even; from there it becomes a question of managing discounts and price elasticity.
- Positive unit economics overall, with a small margin.
- Drivers liked it: many saw they earned more per hour and per kilometer.
- Better retention: riders completed trips at peak hours that they would otherwise have abandoned.
Team, Timeline, Budget
- About 10 people: mobile and backend developers, analysts and a product lead
- 2.5 months from idea to release
- Project cost: about €250,000
Challenges
Why earlier launches failed. The first attempts tried to build a perfect product at once. The stack was less mature, with the monolith making every change more expensive. And the experiment started at an airport. The logic seemed sound — lots of riders go from the airport to the city — but airport riders usually travel in groups with luggage. A car with a full trunk would just pass the gate and get a shared order from a point 100 meters behind, partly because geolocation lags a few seconds.
Gender preferences. Some riders want to ride only alone or only with women. Letting users choose by gender breaks quickly: there is no verification beyond a phone number, so anyone can claim any gender. Segmenting riders also cuts the match rate, and the economics fall apart. The team did not add a gender filter. Instead, riders now state how many passengers they are, so seats add up.
Explaining the product to drivers. Nobody watches onboarding, however good it is. Drivers skip it. Early on, many were confused by the "second order". Cash trips added another layer: it is harder to figure out who pays and who gets out first when two orders run in one car.
What Would Change If Built Today With AI
Not much. The design was drawn by hand in a day or two. AI coding tools would speed up the algorithm code by about 20%, but most of the work is integration between services, where the gain is small. Total time would drop from about 2.5 months to about 2.
AI is not a fit for the real-time matching itself. The platform handles hundreds of orders a minute with heavy geographic data, and an LLM's response time is far too slow. Where AI does help is in finding new hypotheses in large historical data — patterns a team cannot find by hand fast enough.
Where Ride Sharing App Development Like This Applies
The same approach — add pooling to existing dispatch with minimal changes to the driver app — fits:
- ride-hailing and taxi companies with dense order flow and surge pricing;
- corporate shuttle and carpooling app operators;
- delivery and courier platforms that want to batch orders along one route;
- any operator whose taxi dispatch software needs higher utilization without a costly app rollout.
The key lesson: test the riskiest hypothesis first with a cheap backend workaround, and pick a launch zone that matches real rider behavior, not just high volume. This is the kind of work we do in AI dispatch software development and when we scope and ship an MVP.
Related Case Studies
About the Author
Alexander Soldatov — Product Lead, Building Agentic
Ten years in product leadership at Yandex, AliExpress, and Tinkoff. Built Yandex.Scooters operations from zero and scaled the team to 23 specialists; led Yandex.Shuttle; ran cross-border logistics products at AliExpress, launching China and Turkey corridors that delivered 3.5% GMV growth and 25% faster order fulfillment. At Building Agentic he owns hypothesis validation and MVP scoping — deciding what gets built first and what gets cut.
