The chauffeur's working day.
What did this project ship?
The app a Sevenco chauffeur keeps open for a shift. Every active car is a location stream, a fare settled at the end, and a payout that has to land once.
- Row lock
- Background GPS
- Fare true-up
- Cash ledger
- Payout lock
- Session refresh
- Industry
- Mobility
- Country
- India
- Team
- 5 people
- Scope
- Driver app + ledger
Go online, take the trip, collect the fare.
01
A shift is a stream of writes
The rider app opens the request. This app runs from accept until the ledger line is final. The pin the rider sees, the distance that gets billed, and the transfer that leaves the wallet have to be the same trip, including while Google Maps is the app in front.
02
Engineering challenges
The failure is a double dispatch, a pin that freezes behind Maps, a fare the GPS trail invented, a commission that was never debited, a payout that ran twice, or a session that died with a passenger in the car.
- 01The request is a broadcast
Status stays requested while driver_id is empty, so every nearby phone can accept, including from the notification while Maps is in front. Two commits put two cars on one rider. A chauffeur can also accept a request posted from their own rider account.
- 02The OS will kill the process
Turn-by-turn is Google Maps. Android suspends this app, and Xiaomi, Oppo, and Vivo will kill a background task that is not a foreground service. The live point and the billed trail then stop together, and the rider map holds the last fix that got out.
- 03GPS distance is not the route
One-way rates are windows in Asia/Kolkata. A round trip has no booked end, and the meter starts at arrival. Night charge is the overlap of the real interval with the night window. A raw trail wanders off the road. Uncapped, that wander is distance the rider pays for.
- 04Cash and the commission are different books
The rider pays the chauffeur in notes. The commission is a debit on driver_balances, and accept already checked that wallet or the unpaid earnings can cover it. Collecting the cash without the debit leaves the float wrong for the next trip. An online ride has no cash to record and still has to settle.
- 05An eligible earning can leave twice
An online earning waits, then becomes eligible, then a RazorpayX transfer. A scheduled payout and a withdraw the chauffeur taps can both observe that earning as eligible. Two transfers pay the same trip twice.
- 06The token dies inside the shift
The background location task, the ride channel, and chat all present the access token. A shift runs longer than that token. The next point comes back unauthorized, and the car drops off the rider map while the passenger is still in it.
03
How we solved them
A row lock on the ride, a location task that stays up behind Maps, one fare function for the true-up, two ledger lines when the rider pays cash, a lock before RazorpayX, and a token refresh inside the background task.
- One accept holds the row
Accept locks the ride. It still has to be waiting, with no chauffeur on it. The driver has to be online, and not already on a trip. The second call comes back with the ride taken. That same write stores a 4-digit OTP and opens a masked number for the call. The mask closes when the trip settles.
- Location keeps running
A foreground service keeps GPS alive while Maps is in front. Live points and saved points are separate writes. A late fix is dropped. Points that fail to send wait on the phone and survive a restart, with the access token refreshed in that same background task.
- One fare function
One-way rates come from time windows in Asia/Kolkata. The booked amount is the estimate. End photos send the trip back through the fare function: the trail can raise it, night charge is taken from the actual start and end, and the coupon is applied to that new amount. The drop point is the phone's, or the last point saved on the trail. Round-trip billing starts when the chauffeur marks arrived. The collect screen and the rider notification use that same figure.
- Cash writes two lines
Collecting cash records the earning and takes the platform fee from the wallet. The chauffeur can go online when the wallet or unpaid earnings cover the minimum float. An online ride settles before the trip is completed. A coupon uses the payable fare stored at booking.
- Payout states stay apart
An online earning waits 24 hours, then becomes eligible. The transfer takes a lock on that driver before RazorpayX sends it. The chauffeur can also request the withdrawal to a saved bank account or UPI. Cash stays on the wallet statement and does not enter that payout queue.
- The session refreshes on the road
Background location refreshes the access token before the next write. Ride channels reconnect when the token is close to expiry. Chat uses the live channel and polls if that channel drops. A short network failure refreshes the session in place.
04
System design
One ride row owns the status. The live map and the billed trail are separate writes, so a stalled broadcast does not erase the path the fare is computed from. Money is a statement, not a balance someone edited.
- 01The ride row is the lock
Accept, arrive, OTP, photos, start, a stop, drop, collect, complete, and cancel each lock the ride before they write. Going online locks the driver row. The phone can tap twice. The database keeps a single status.
- 02A live pin, and a saved trail
The rider map follows a broadcast every second. History uses a write every five seconds. A move under 3 metres does not add a trail point, and the trail keeps the latest 500. The marker glides over 800 milliseconds. Speed is snapped to the road, and falls back to the raw fix when that call fails. The live point goes out through an authenticated function, and a ride that is no longer active is not sent on. The drawn route shortens to the car. A fix far off that line leaves the original road in place.
- 03Money is a ledger
Earnings, platform fees, top-ups, adjustments, and payouts are lines in one statement. The float check reads the wallet and unpaid earnings together. The payout lock is per driver. A top-up, a ride payment, and an automatic payout each carry their own key, so a retried webhook writes the line once.
- 04New requests only while idle
The channel is open when the chauffeur is online and has no active trip, and it only carries trips that are still waiting. A poll every three seconds covers an event the channel missed. A decline is remembered for that session and cleared when they go offline. Up to 60 location points wait on the phone, each tried 12 times, for up to an hour.
- 05The server decides who may work
Go-online and accept both pass through the same gate: app version, a booking pause, a critical alert, and the phone's location. The app shows the block it was given.
- 06Fare is calculated in one place
The phone timer reads the arrival time stored on the trip, including after the app has been killed. Night charge is one overlap of that interval with the night window. B2B rates, a booked package, overtime, and a coupon are inputs to the function the rider is charged from.
05
What a trip includes
The working day, from the request that is still open to the line that shows up on the wallet after the trip.
- 01The request
Route preview, a fare breakdown, a B2B mark when it applies, and the vehicle the rider asked for. Accept and decline sit on the sheet and on the notification, including while Maps is in front.
- 02On the way to pickup
The route, navigation, chat with the rider, and a masked number once the call mask is active. A bubble over other apps brings the chauffeur back from Maps. Phones that kill background work, including Xiaomi, Oppo, and Vivo, get a separate prompt so the pin stays alive. Upcoming scheduled rides stay listed on the Rides tab.
- 03At the car
A 4-digit OTP, a face photo, and photos of the vehicle. The round-trip meter is already running from the moment of arrival.
- 04Under way
Mid-stops can be marked as reached. The pin, the trail, and the running fare keep updating with the phone in the mount.
- 05Collection
Photos at the end, then the amount to take from the rider and the amount kept after the fee. A ride that is already settled online skips the cash prompt.
- 06After the trip
Ride history, a support report tied to that ride, and the earning on the wallet statement. The driver guide, with its training videos, is there for the next shift.
06
What we built
We shipped the Sevenco driver app for Android, on the same backend as the rider app. Accept, the location stream, the fare true-up, cash collection, and the payout all write through that backend.
07
Runtime
Clocks and caps from the running driver app.
Position sent on an active trip
Point saved on the trip
Older fix is ignored
Glide between fixes
Move before a point is kept
Points kept on the map
Off the road, the drawn line stays
Extra distance before a one-way fare rises
Cap on the billed GPS distance
Points held while offline
Tries for a failed write
Poll if the channel misses one
08
What we delivered
- Sevenco driver app for Android
- OTP sign-in, a verification hold, and profile editing
- Go-online check against the wallet float, unpaid earnings, app version, and service blocks
- Incoming requests with the route, fare breakdown, B2B mark, and vehicle preference
- Accept and decline, including from the notification while another app is open
- Scheduled rides listed before their window
- Pickup OTP, a face photo, and vehicle photos before the trip starts
- Vehicle photos at the end of the trip
- Mid-stops marked as reached
- In-ride chat
- A masked call once the mask is active
- Live location in the foreground and while Google Maps is open
- A return bubble over other apps, and a battery prompt so Android keeps the pin alive
- Road-snapped speed, with a fallback to the raw fix
- Per-kilometre rates by time of day, a minute meter from arrival, package overtime, and night charge
- Cash collection and online settlement, including a coupon's payable fare
- Wallet, ledger, top-up, bank accounts, UPI, and payouts
- Ride history, a support report on a ride, and ticket follow-up
- Driver guide with training videos
- In-app notifications, and an offline banner when the network drops
09
Technology
- React Native
- Supabase
- Firebase
- Google Maps
- FCM
- RazorpayX
Live product
In production.
The driver app is on Google Play. The rider app has its own case study.