01 — The situation
One app, five services, two sides to every one.
Our client wanted a single app carrying several services at once: rides, car hire, delivery, and a wallet to pay for all of it. Not five separate apps — one, with one account and one balance.
What made it hard wasn't the number of services but the fact that each one has two sides that must find each other: a passenger placing an order and a driver accepting it. Both are moving, both are in a hurry, and both are on a phone in traffic.
02 — The problem
Two things you cannot buy off the shelf.
Most of what a system like this needs already exists ready-made. Two things did not.
Finding the nearest driver. It sounds simple until there are thousands of them spread across a city. Measuring the distance to every driver on every order is impossible — orders arrive every second, and the drivers keep moving.
Calculating fares on a looping route. The route isn't a straight A to B. Vehicles circle through a series of stops, and a passenger can board at any stop and alight at any other — including one that takes them almost the whole way around. Each segment has its own fare, and the total has to be right no matter where someone gets on.
These two had no recipe to copy. We derived them ourselves.
03 — What we did
Deriving two algorithms from reasoning, not from examples.
Four decisions settled it.
- 01
Filter roughly first, measure precisely after
To find the nearest driver we don't measure every driver. The map is first cut down to a box around the passenger, and only drivers inside that box get measured properly. Filter cheaply, then measure expensively — that is what keeps it fast as the fleet grows.
- 02
Distance measured across a curved surface, not a flat page
The distance between two points on a map isn't an ordinary straight line; the earth curves. We measure along that curve, so that “nearest” matches the road rather than the drawing.
- 03
Fares summed per segment, not per total distance
The loop is broken into short segments between stops. A trip's fare is the sum of the segments actually travelled, counted in the direction of the loop. Boarding at the last stop and alighting at the first is then priced correctly — rather than treated as a short hop when it is nearly a full circle.
- 04
A wallet built to be audited, not merely to decrease
Top-ups, withdrawals, bonuses, and payments are all recorded as history that cannot be altered — not as a balance that simply moves up and down. When something doesn't add up, the question becomes “which entry disagrees” rather than “why is the balance wrong”. That is the difference between a problem you can trace and one you can only guess at.
04 — The outcome
Released publicly, then grown for three years.
The apps shipped on both stores and were used by real passengers. Services were added in stages, and the system grew into separate parts so each service could be developed without disturbing the others.
The team grew from four people into more than a dozen. We kept writing code while dividing the work — rather than moving into a supervisory seat and reading reports.
05 — What keeps it standing
We still use both algorithms today.
Finding the nearest thing, and summing costs that differ per segment, turned out not to be about vehicles at all. The same shapes reappeared in systems we built years later.
We derived them from reasoning rather than copying them. The consequence is that we understand why every part is there — so when the requirement changes, we know which parts may move and which will quietly break the arithmetic.