Case study
Ride-hailing for construction sites: the client calls out a worker the way they call a car — sees them on the map, watches them approach, and pays for what was actually done. Android and iOS apps, nearest-worker matching, live coordinates.
The problem
Finding a worker for a site means working the phone: the client rings round the foremen they know, the foreman rings round his own crew, and hours go by. Afterwards nobody can say exactly what the job cost or when it started.
The task was to match client and worker as fast as a taxi does: whoever is free and closest gets the job. With the difference that this happens on a building site.
What we did
Built for bad conditions
A building site means weak signal, dead phones and dirty hands. Three decisions were made precisely because of that, and each one shows up either in the bill or in reliability.
Sign-in without mobile data. The number is confirmed not by SMS but by a flash call: the phone rings for a couple of seconds and hangs up, and the code is the last digits of the number. It works where there is no data at all, and costs a couple of tenge instead of about twenty-five for an SMS.
Matching without a background scheduler. The search radius is a function of the job’s age, not the result of a timer firing. A job that has been searching for five seconds is offered within three kilometres; a job that has been searching for a minute has already found nobody nearby and reaches further. Nothing has to be remembered between requests, so a server restart loses nothing.
A double tap breaks nothing. Every transition in a job is one conditional update in the database, checking the status the job is leaving. The database decides, not a read followed by a write. On a bad connection, two taps will not start the timer twice or bill twice.