Ride hailing
Two apps and a map is the part everyone can picture. The system underneath is a real-time marketplace that has to stay consistent while thousands of people change their minds at once.
The maps are the easy part. The difficulty is that supply and demand are both moving, both impatient, and both able to withdraw at any moment. A ride exists in a chain of states — requested, offered, accepted, started, completed, paid — and every transition can be raced by a cancellation, a lost connection or a driver who accepted two things at once. Get that state machine wrong and the failure is not a crash; it is two drivers arriving for one passenger, or a completed trip nobody can charge for.
Three subsystems carry most of the risk. Matching decides who gets offered what, and a naive nearest-driver rule quietly starves the edges of your map and trains drivers to game it. Pricing has to be defensible: a fare a passenger disputes is a fare you refund, so the calculation needs to be reproducible from stored inputs rather than recomputed from a moving world. And location is a firehose — continuous updates from every active driver, most of which nobody needs at full resolution, which is why the naive version is the line item that surprises you on the infrastructure bill.
What travels between markets is the shape: the state machine, the dispatch model, the reconciliation. What does not travel is everything touching money and law — payment rails, driver payouts and their tax treatment, licensing, how addresses actually work where you operate. Adapting a known shape means keeping the first and rebuilding the second deliberately, rather than discovering in month four that the payout model assumed a country you are not in.
How we work
- The trip state machine is written down and tested before any screen is designed. Everything else in the product is a view onto it.
- Fares are reproducible from stored inputs, so a disputed charge can be explained rather than argued about.
- Location updates are throttled and downsampled at the edge. Full resolution is kept for the active trip and almost nowhere else.
- The operations console is built alongside the apps, not after them. Without it, every edge case becomes a phone call to an engineer.
A rider app home screen. Choosing a tier changes the fare and the estimate.
What this includes
Pick what you need and send it over.
Questions
- Do we need both apps to launch?
- You need the driver side and the operations console. The first version of the rider side can be a web app, and in a single city with a recruited fleet, early dispatch is often better handled by a person with a good console than by an algorithm tuned on data you do not have yet.
- Can this be adapted for deliveries instead of passengers?
- A large part of it, yes — the dispatch model and the state machine are close relatives. The differences are real though: parcels wait, batch together and have a handover to prove, none of which is true of a passenger.