Live dispatch for a chauffeur, not a cab.
What did this project ship?
The app a rider uses to ask for a chauffeur for the car they already own. The database stores the fare. This phone only orders the pin and pays once, at collection.
- Server fare
- Ordered pin
- Push
- Drop agreement
- One charge
- Search clock
- Industry
- Mobility
- Country
- India
- Team
- 5 people
- Scope
- Rider app
Set the pickup, follow the pin, pay at the end.
01
This phone does not price the trip
Sevenco sends a chauffeur to a car the rider already owns. This phone shows the request, the pin, and the receipt. The fare, the order of the fixes, and the charge are decided with the driver app on the same ride row.
02
Engineering challenges
After confirm, the fare, the pin, the locked phone, the real stop, the charge, and the search can each disagree with the ride row. Support then has two figures, a car that jumped, or a payment that ran twice.
- 01The confirm screen prices the trip
Distance, the coupon, and the night window are already on the phone. A total added up there is not the total request_ride_secure stores from get_fare_rates_for_user. The receipt and the screen the rider agreed to will not match.
- 02Three feeds, one marker
The broadcast, the driver row, and the poll each carry a fix, and they do not arrive in order. A chauffeur phone with a wrong clock makes an older point look newest. The car jumps backward on the map the rider is watching, and the route time follows it.
- 03The process is suspended
The match, a chat line, and a fare that changed after the end photos have to reach a locked phone. If they only exist while this app is in front, the rider misses the chauffeur at the door.
- 04The billed stop and the booked pin
The last point on the trail and the booked drop can be a kilometre apart. The trail can also price the trip above the booking. Charging the booked figure, or charging the new figure with no agreement, leaves one side short.
- 05Three tenders, one trip
Collection can be cash, the rider wallet, or a Razorpay checkout. A dropped connection retries the same checkout. Two successes charge the trip twice, and the ledger has no single payment to point at.
- 06A search with no clock
No chauffeur may be free. A ride for later that is broadcast now wakes every nearby driver for a pickup that is not due. A ride left in scheduled past its window never reaches the drivers who are online, and the rider waits on a request that is no longer in the market.
03
How we solved them
request_ride_secure stores the fare. This phone orders the fixes by the time it received them. The charge is a server write that recognises a repeat, and it runs when the trip is in collection.
- The server prices the request
A one-way trip has to bring a distance from the route function, between 0 and 1,000 km. The database prices it from that rider's rates, the time window, and the night charge. A coupon row is locked and checked before the ride is inserted. The same write stores a 4-digit OTP.
- One ordered marker
The broadcast moves the pin first. The driver row is a second stream. A poll covers the gap until the channel confirms, and a slower poll continues after that. A repeated timestamp is dropped. An older fix is held back. Freshness uses the time this phone received the point, so a wrong clock on the driver phone cannot freeze the pin.
- The trip keeps moving off screen
Status changes go out as push. Chat uses the live channel, allows fifteen seconds for the socket, and polls if that socket does not open. Coming back to the app refreshes the pin. The route time is asked again every minute.
- The drop is confirmed
On a one-way trip, an actual drop past the configured threshold asks the rider to agree before the payment stands. The amount on the collect screen uses the same figure as the notification, including when the trail raised the fare. A round trip shows its clock from arrival. A one-way trip does not add a waiting charge.
- Money writes once
Cash, the rider wallet, and Razorpay settle when the trip is in collection. Paying from the wallet and confirming a Razorpay checkout go through server writes that recognise a repeat. A checkout that never finished can be abandoned and started again.
- Search has a clock
A request looks for a chauffeur until the configured timeout. A booking inside the schedule window is sent out immediately. One further out stays scheduled until that window.
04
System design
This app subscribes. The ride row is the record the driver app writes. The pin is one ordering step in front of three feeds, so a late poll cannot drag the marker backward.
- 01The ride row is the record
Request, schedule, accept, arrival, photos, start, collect, and complete are statuses on that row. The rider screens follow it.
- 02Three inputs, one pin
Broadcast, the driver row, and the poll all pass through one ordering step before the marker moves. The marker glides over one second. Inside 500 metres the camera follows the car. Beyond that, driver and pickup stay in one frame. Inside 300 metres the chauffeur counts as nearby.
- 03Fare is calculated in the database
Booking stores the estimate from the rider's rates, including a B2B rate when that account has one. End photos recompute a one-way fare from the trail and the actual night window, then apply the coupon again. This app shows that result.
- 04Pay when the trip is in collection
Confirming the ride does not charge the card. Cash, wallet, and Razorpay run at the end. Each of those writes carries an identity the server has already seen, so a retry does not settle twice.
- 05The server allows the request
Leave-now and schedule both pass a gate: app version, a booking pause, a critical alert, and the pickup location. The app shows the block it was given.
- 06Chat, the call, and the profile stay on the ride
Messages are for that trip. The masked number is the one opened when the chauffeur accepts, and it closes when the trip settles. After the trip, the rider can still see the chauffeur's name and vehicle without the live location.
05
What a trip includes
The trip as the rider meets it: the request, the search, the approach, the car, the charge, then the receipt.
- 01The booking
Pickup, drop, and mid-stops. One-way or round trip, leave now or later. Transmission and the car they want noted on the request. A coupon previewed before it is reserved.
- 02The wait
The request is live for nearby chauffeurs. The search ends on the timeout. A later booking stays on the schedule until its window.
- 03The approach
The pin, a route time that refreshes, chat, and the masked number once the call mask is active. The map pulls in as the car gets close.
- 04At the car
The chauffeur arrives, checks a 4-digit OTP, and takes the start photos. On a round trip the clock is already running from arrival.
- 05Payment
Cash, the wallet, or Razorpay. If the car finished far from the booked drop, the rider agrees to that stop. A coupon uses the payable fare stored on the trip.
- 06After the trip
The receipt, the chauffeur's details, a rating, and a report tied to that ride. A referral code can be shared for the next signup.
06
What we built
We shipped the Sevenco rider app for iOS and Android with a Java and Go backend. The request is priced in request_ride_secure, the pin is ordered on the phone, and the charge runs once at collection.
07
Runtime
Clocks and caps from the running rider app.
Glide between driver fixes
A pin this old is marked late
After this, the ETA is hidden
Backup while the channel is down
Backup once the channel is up
Route time refreshed
Driver treated as close
Map follows inside this
How long a request looks
Inside this, a booking goes live
Time allowed for the socket
Actual stop asks the rider to agree
08
What we delivered
- Sevenco rider app for iOS and Android
- OTP sign-in, a profile, and a referral code on signup
- Pickup, drop, and mid-stops, with the route calculated on the server
- One-way and round trip, leave now or schedule
- Transmission and car model stored on the request
- Coupons previewed and reserved in the database
- A server-priced fare, including a separate B2B rate
- A chauffeur search with a timeout
- A live pin from the broadcast, the driver row, and a backup poll
- A route time that refreshes, a nearby state, and a camera that closes in
- In-ride chat and a masked call
- A 4-digit OTP, and a round-trip clock that starts at arrival
- Cash, wallet, and Razorpay, with a checkout that can be recovered
- Agreement when the car stops far from the booked drop
- A receipt, the chauffeur's details after the trip, a rating, and a ride report
- Push notifications, an offline banner, and a forced update
09
Technology
- React Native
- Java
- Firebase
- Go
- Google Maps
- FCM
- Razorpay
Live product
In production.
Rider, driver, and the backend they share are in production.