Live dispatch for a chauffeur, not a cab.
Sevenco is a chauffeur marketplace for people who already own the car. We built the rider app, the driver app, and the backend that requests a verified chauffeur, follows them in, and closes the trip.
- Concurrent matching
- Live GPS
- FCM
- Realtime
- Haptics
- Wallet
- Industry
- Mobility
- Country
- India
- Team
- 5 people
- Scope
- Two apps + backend
The rider loop: request, match, watch the driver move.
01
The inversion
Most mobility products move a fleet car to the customer. Sevenco keeps the car where it is and moves a professional driver to it. The chauffeur arrives on a foldable bike and stows it in the trunk. That is not a skin on ride-hail. The inventory is people, not vehicles, and the rider has to trust a stranger with a car they already own.
02
What the system has to survive
A live chauffeur marketplace does not fail in the booking form. It fails when two trips collide, the pin is stale, or the rider has already locked the phone.
- 01Overlapping claims
Two live requests can compete for the same chauffeur. If both hold the driver, one trip is a lie.
- 02Stale location
The chauffeur is moving. A last-known pin that is thirty seconds old sends the rider to the wrong place. Stale is worse than empty.
- 03Phone locked
Riders lock the phone at the door. The trip does not pause because the UI is not visible.
- 04Wrong entrance
A pickup that is only close enough puts the chauffeur on the other side of the building.
- 05Settlement race
Charge before the trip is real and the rest of the product is unwinding a payment that should not have happened.
- 06Presence without staring
Rider and chauffeur have to feel each other without both watching the map.
03
How we solved it
Each failure mode has a corresponding write, stream, or event. The rider UI is a projection of that work.
- 01Trip as source of truth
One trip record moves through requested, matching, assigned, en-route, arrived, in-trip, and complete. Each screen is a projection of that record.
- 02Exclusive assignment
Matching looks up nearby eligible chauffeurs and writes a single claim. The write has to win when two requests overlap.
- 03Location as a stream
The driver device publishes coordinates. Supabase Realtime fans that stream to the rider map. Polling a last-known point is not the same system.
- 04Events off-screen
Match found, approaching, status change. Firebase Cloud Messaging delivers those while the app is backgrounded.
- 05Exact pickup first
The rider pins the entrance on Maps before matching starts, so the chauffeur is not sent to the building instead of the door.
- 06Settlement last
The wallet is the terminal transition. It runs after assignment, approach, and arrival — not as a checkout that races the trip.
04
How we optimized
Realtime is expensive if every device listens to everything. The rider app stays cheap by being a subscriber to one trip.
- 01Trip-scoped channel
Subscribe to this trip, not the marketplace firehose. Nearby noise never reaches the rider session.
- 02Pin, not map rebuild
Throttle and smooth the marker. Do not tear down the map on every GPS tick.
- 03Publisher vs subscriber
The moving device spends battery publishing. The rider listens. Cost sits on the party that is in motion.
- 04Typed push
The notification says what happened — match, approaching, arrived — not "open the app and find out."
- 05One store
Screens project the trip record. There is no second client copy to drift from the server.
05
Nothing waits for a refresh
This is not a page you reload. Match, motion, arrival, and settlement arrive as they happen — including in the hand.
- 01No pull as source of truth
Pull-to-refresh is a dashboard habit. Here the trip record moves, and the screens follow. The rider does not poll to learn whether they have a driver.
- 02Events, not pages
Match found, chauffeur approaching, arrived, in-trip, complete. Those transitions land as live events because the session changed, not because the user asked again.
- 03The pin is a stream
The chauffeur's device publishes coordinates. The rider map interpolates that stream. A last-known point fetched on an interval is a different product.
- 04Haptic with the driver
Match, approaching, and arrived also hit the hand. A pulse on the rider phone is the chauffeur knocking — even when the phone is in a pocket and the screen is off.
- 05One live session
Rider and chauffeur share the same trip. Presence is the session itself: both sides are looking at one moving record, not two apps that occasionally sync.
06
What we built
AonHive designed and built Sevenco end to end: Expo apps for rider and driver, and the backend those apps share. The work was the trip as an operating loop: set an exact pickup, match a driver, keep the rider informed while the chauffeur is en-route, and settle only when the trip is actually over. Maps, the trip store, realtime location, and push sit under that loop. They are infrastructure, not the product.
07
What we delivered
- Sevenco rider app for iOS and Android
- Driver app for Android
- Trip backend: exclusive matching, location stream, and settlement
- Booking flow: destination, exact pickup, leave-now or schedule
- Live trip session: driver identity, map stream, no pull-to-refresh as source of truth
- Haptic trip events on match, approaching, and arrived
- In-app wallet at trip close
08
Technology
- React Native
- Supabase
- Firebase
- Google Maps
- FCM
- In-app wallet
Live product
In production.
Rider, driver, and the backend they share are in production.