A driver-first network where an independent taxi driver, travel agent or fleet owner can pass a booking to a trusted driver, keep the customer relationship, and give the passenger a professional live-trip link. Concept designed from nine years of working with drivers.
At a glance
The problem
Drivers already pass bookings to each other in WhatsApp and Telegram groups, one of them with 31,715 members. The groups have no booking status, no records and no safe way to settle payment.
What I designed
A driver-first network where a driver, agent or fleet owner passes a booking to a verified driver, keeps the customer, and settles through the app.
The evidence behind it
Nine years of working with drivers, published reports and market coverage, and a review of the products drivers use today.
My role
Sole product designer: research, strategy, UX, UI, design system and prototype.
Three decisions that shaped it
How I know it works
Completed handoffs per active verified driver each week
Read it
01
Independent taxi drivers already pass bookings to each other in WhatsApp and Telegram groups. After nine years of working with drivers, I wanted to design what that workaround would look like as a proper product, built around the driver’s own customers.
02
The strongest finding was not a gap in the market. It was a workaround that drivers have already built, at scale, in apps that were not made for it.
31,715
members in one Bengaluru duty group
A second group had 24,530. Both are on Telegram.
40-50
duty groups in Bengaluru, by one driver’s estimate
Some carry only driver-to-driver work. Others mix in travel agents and company transport staff.
80%
minimum fare share for drivers using their own vehicle
Under the 2025 central aggregator guidelines, which states still have to adopt.
03
I looked at four kinds of product that drivers could use today. Each solves part of the problem, but none starts with the driver’s own customer.
Each dot is a product. Left to right shows who keeps the customer: the platform or the driver. Bottom to top shows how organised the booking is, from chat and phone calls to status and records. The green corner is the space nobody covers.
Organised, but the platform keeps the customer
Organised, and the driver keeps the customer
Informal, and the platform keeps the customer
Informal, but the driver keeps the customer
WhatsApp and Telegram duty groups
Drivers trust them and already use them. But there is no search, no booking status, no record, and the same duty gets posted again and again.
Agent-to-driver marketplaces
A separate app, focused on outstation trips and mainly in North India. Its published model has agents posting bookings and drivers paying commission to the agent.
Ride-hailing aggregators
They own the rider. Several have moved from commission to subscription, so zero commission alone is no longer a difference.
Outstation and airport cab apps
Built to sell trips to passengers, not to let a driver pass on their own customer.
The gap I saw
04
Three kinds of input, one picture: what I have seen first hand, what has been published, and the hypotheses that follow from both.
Experience
Nine years of working with drivers, from conversations and from watching how duties really move.
Desk research
News, government guidelines and published studies on the Indian taxi market and driver economics.
Competitor review
Duty groups, one agent marketplace, aggregators and outstation apps.
Roles and scope
Four roles in a handoff, and a deliberately narrow slice to design well.
05
This is how a booking moves in a duty group, from my experience. Posts are typed or sent as voice messages, and everything after that happens by phone.
Someone posts the booking
A driver, agent or company posts the trip in the group as text or a voice message, and asks who is available.
A driver calls
A driver who is interested phones the person who posted.
Details are shared
The driver shares their own details, and gets the booking information by phone or text.
The trip happens
The driver completes the trip.
The driver is paid
The driver takes the payment, usually from the customer.
06
From nine years of working with drivers. The same few problems come up again and again.
The wrong driver turns up
The driver who accepts is not always the driver who comes. The vehicle details shared when accepting can differ from the vehicle that reaches the customer.
No-shows
The driver who accepts never arrives, and does not pick up the phone.
Late payment
Money often does not arrive on time. Some drivers press the customer or the person who posted to pay at the airport toll, and drop the passenger there if it is not paid.
Money is by understanding
Usually the driver who completes the trip is paid. Sometimes the person who posted collects and pays later. Some posters keep a percentage and some a fixed margin, agreed between the two, and paid in cash or by UPI.
Paper duty slips
Fleet owners use a physical sheet with the odometer readings, total km, start and end time, vehicle and driver details. The driver fills it in and hands it over, and the agreed payment follows after the ride.
No shared language
Drivers in Bengaluru use Kannada, Tamil, Telugu, Hindi and English, in any mix. No single language fits everyone.
07
These roles come from my experience with drivers and from how duty groups work. Each carries a hypothesis that the next round of research validates.
The posting driver
Has the customer, needs someone to drive
Has built up their own customers, often from years of driving for ride-hailing apps: they give good service, share their number and offer to book directly. When they cannot take a booking, they post it in a group and hope the right driver turns up.
Hypothesis. If a driver can hand off a duty safely and stay in charge of the relationship, they will use it for every booking they cannot take.
The accepting driver
Takes the duty and drives
Has a verified vehicle and some idle time. Wants good trips and clear money. Needs to trust the person handing the duty over.
Hypothesis. If the fare, the payout and who collects are clear before accepting, drivers will take duties from people they do not know well.
The booking source
Travel agent, company or fleet owner
Has bookings of their own: a travel agent with a tour, a company arranging staff cabs, a fleet owner with a corporate contract and too few drivers. Fleet owners today rely on a paper duty slip the driver fills in and hands back, then pay once the ride ends.
Hypothesis. If they can post a duty to verified drivers and see the status and records, they will move bookings off WhatsApp.
The passenger
The person who rides
Booked a driver they know and now gets someone else. Needs to be told, to see who is coming, and to feel safe. Has no app and will not install one.
Hypothesis. If a passenger gets a clear link with the driver and vehicle details, they will accept a different driver.
08
The questions I put to drivers, agents and fleet owners next, each with a clear way to test it.
How much comes from their own customers
In my experience it is most of it, but I have no number. Test: a short survey in a duty group.
Circles or open feed
Do drivers prefer small trusted groups or a city-wide feed? Test: compare both in a paper prototype.
Money and trust
What do drivers need to see before accepting from a stranger? Test: show fare and payout variants.
Verifying papers
Can documents be checked automatically, or only by a person? Test: ask the data providers.
09
Five rules I set before drawing any screen. Each one answers something I have seen go wrong.
The person who brings the customer keeps the relationship
The passenger’s details stay protected, and the poster stays in charge of the customer they brought.
Show the money before anyone accepts
Fare, commission, fees and who pays are visible first, so there is nothing to argue about later.
Drivers choose, nothing is assigned for them
Duties sit in a feed and a driver accepts the ones they want, at the fare shown.
Trust before scale
Verified drivers, verified vehicles and a locked assignment come before any growth feature.
Built for a parked driver
One hand, a basic phone, a bad network, and any mix of Kannada, Tamil, Telugu, Hindi and English.
10
Six decisions shaped the handoff. Each one answers a problem I have seen in the groups.
01
Drivers choose, nothing is assigned
Options I weighed
Why
Drivers decide which duties they take, at the fare shown. It matches how duty groups work and keeps the poster in control of who drives.
02
Payment goes through the app, with a hold
Options I weighed
Why
Late payment is where handoffs break, down to drivers pressing customers at the airport toll. A hold with automatic release removes the argument.
03
Passenger details only after accepting
Options I weighed
Why
The driver who brings the customer keeps the relationship. Details are shared only once someone has committed to the duty.
04
Lock the driver and the vehicle
Options I weighed
Why
The wrong driver or vehicle turning up is a core problem today. A swap needs the poster’s approval and the passenger is told.
05
Commission stated up front
Options I weighed
Why
Today some posters take a percentage and some a fixed margin, settled by understanding. Making it visible before anyone accepts removes surprises, and a forfeited commission discourages casual accepting.
06
The passenger needs no app
Options I weighed
Why
Passengers booked a driver they know. A link on WhatsApp shows the driver, the vehicle and live status, with nothing to install.
11
The slice I am designing: handing a duty to a trusted driver, and the Garage that makes a driver trustworthy. Everything else stays on a visible roadmap.
Hand off
Create a duty
A structured booking for four trip types: airport, local, outstation and rentals. Pickup and drop, time, vehicle type, passengers, luggage, fare, tolls, how the passenger pays and any commission.
Choose who sees it
One named driver, a trusted circle, or a verified city marketplace after a set time.
A feed of verified drivers
Agents and fleet owners post to a feed that only verified drivers can see. Drivers look through the feed and accept a duty at the stated fare. The poster waits until someone is interested. Nothing is assigned automatically.
Type or speak
Drivers already post by typing or by voice message. Either way, the post becomes the same structured duty, checked before it goes out.
Simple chat to agree details
A short in-app text thread for negotiating, so details are not lost between phone calls.
Trust
The Garage
A driver’s identity and vehicles: driving licence, Aadhaar and registration certificate. Aadhaar is used only to verify and is never stored in full. Status and expiry alerts keep papers current.
Locked assignment
Once a duty is accepted, the driver and vehicle are locked. A swap needs the poster’s approval and tells the passenger.
Reliability from real duties
Punctuality, completion and payment conduct, explained and open to appeal.
The passenger
A web trip link
Driver and vehicle details, ETA and live location while the trip is on. No account, no app, expires after the ride.
Consent and safety
The passenger is told when the driver changes, and can reach help from the same page.
Details only after accepting
The passenger’s name and phone number stay hidden until a driver accepts the duty.
Settle
The money, up front
Fare, tolls, parking, payout, who pays and any commission, all visible before a driver accepts.
Two ways to pay
When creating a duty, the poster chooses: the passenger pays the driver directly (cash or UPI), or the poster pays online through the app.
If the passenger pays the driver
A poster who wants a commission states it, as a percentage or an amount. The accepting driver pays it through the app when they accept, with the gateway fee added to what they pay. Without a commission, the driver keeps everything.
If the poster pays online
The poster pays through the app as soon as a driver accepts: the fare minus any commission, plus the gateway fee. The driver is paid from that.
Held, then released
Either way, the app holds the money until 30 minutes after the trip is complete. If no issue is reported, it goes automatically to the other driver’s bank-verified account. An issue reported in that window holds it while it is looked at.
A digital duty slip
Replaces the paper sheet: start and end odometer, total km, start and end date and time, vehicle type and details, and driver information, shared with the fleet owner or agent.
When it goes wrong
Report an issue
Either driver can report one within 30 minutes of the trip ending: the driver did not turn up, the wrong driver or vehicle came, the passenger paid less than promised, or the trip details were wrong. A reviewer checks the duty record and decides.
Cancellation, with a cost
Cancelling is free until one hour before pickup. After that, a driver who cancels forfeits the commission to the poster, so no one accepts casually and then drops out. A poster who cancels loses a penalty of 10% of the trip amount, and the rest is refunded. The figure is a starting point to test.
A clear record
Every duty has a status, a time, an accountable source and a fulfiller, so a review has evidence.
12
Each problem from the groups, and the design decision that answers it.
What goes wrong
The wrong driver turns up, in a different vehicle
The design answers
Driver and vehicle lock when a duty is accepted. A swap needs the poster’s approval, and the passenger link updates and tells the passenger.
What goes wrong
The driver who accepts never arrives
The design answers
The duty shows live status (en route, arrived), the poster is alerted if pickup time is close and nothing has moved, and the duty can be posted again in one tap.
What goes wrong
Payment is late, and drivers press the customer at the toll
The design answers
In online mode the poster pays when the driver accepts, the app holds it, and releases it 30 minutes after the trip if no issue is reported.
What goes wrong
The poster’s margin is by understanding
The design answers
Any commission is stated before anyone accepts, itemised, and paid through the app.
What goes wrong
Fleet owners track trips on paper slips
The design answers
A digital duty slip carries the same details: odometer, km, times, vehicle and driver.
What goes wrong
There is no shared language
The design answers
Key states use icons and short words. Drivers can post by typing or by voice, and the post turns into the same structured duty. Kannada and English come first.
13
The idea is bigger than this case study. I kept the first release to what proves the handoff works, and put the rest on a visible roadmap.
A social feed and groups
Drivers already have WhatsApp for this. The handoff has to work first.
Services and rewards
Insurance, fuel offers and points only matter once there are completed duties.
A full business desk
Earnings, expenses and invoices come after trust is established.
Fleet and association tools
One fleet owner posting a duty works now. Managing a whole fleet is a later layer.
14
Measures I would track, chosen to show whether the handoff is trusted, not how many people installed the app.
Completed handoffs per active driver
The main measure: duties finished, per verified driver each week.
Time to fill
How long a duty waits for someone to accept, compared with a group post.
Completion after accepting
How many accepted duties are finished, and the no-show rate.
Disputes and payouts
Disputes per 100 duties, and the share of payouts released with no issue reported.
16
This section fills in as I finish it: the flows, a design system for one-handed use on a low-end phone, the screens and an interactive prototype.
Flows
Create a duty, offer it, accept it, run the trip, settle.
In progress
Design system and screens
Components, states and the Garage, in English and Kannada.
In progress
Interactive prototype
Embedded here, so you can use it.
In progress
There is more behind this
11 more sections, about 11 minutes of reading.
Want the walkthrough now?
The full case study is being written. I am happy to talk you through it in the meantime.
