drivin
drivin is a local mobility service for people who already drive. Everyday drivers share the routes they drive anyway or lend cars that sit unused, while riders nearby request same direction pickups or borrow a vehicle when they need one.
Taxi and rental apps run on professional supply. drivin runs on routines: who is already going your way, whose car is already parked nearby, and when. Matching starts from route overlap, schedule, and trust rather than dispatch.
Client
Personal Project
Year
2024
Project type
Mobile App / Local Mobility / P2P Car Sharing
Credits
Product Design, React Native Prototype
Mobility apps serve taxis and fleets. Everyday drivers were left out.
Existing mobility apps were built for taxis or rental companies, not everyday people sharing real routes
Ride hailing apps assume a professional driver waiting for dispatch. Rental apps assume a company owned fleet.
Meanwhile, many people drive the same routes every day, and their cars sit parked for most of it.
That everyday supply had no product built for it.
Neither side was served. Drivers had no way to earn from routines they already had, and riders had nothing between hailing a taxi and renting from a company counter.
Research
The problem was not finding a ride, but trusting a stranger's car
I explored how people feel about sharing a ride or borrowing a private car from someone nearby.
The biggest barriers were not price or availability. They were trust. Safety, vehicle condition, payment protection,
and what happens when someone cancels.
Trust
Both sides need verification, payment protection, cancellation rules, and vehicle condition records before the service feels safe to use.
Everyday Driver
Drivers wanted to earn from routes they already drive and cars they already own, without operating like a professional taxi service.
Mobility User
Riders needed flexibility for specific times and purposes. Ride-hailing felt too immediate, rentals too rigid, and both too separate from each other.
How might we?
How might we let ordinary people share routes and cars safely, in a service that feels nothing like calling a taxi or renting from a counter?
My Role
I designed the product structure and both sides of the service
As the sole product designer, I defined the service concept, user flows, information architecture, and mobile interface.
The core structural decision was splitting the app into two modes: Usage Mode for people who need mobility,
and Earning Mode for people offering routes or vehicles. One account, two clear intents,
and no screen that tries to serve both at once.
Key Contributions
01
Market and competitor research
02
Product concept and positioning
03
Route based ride matching logic
Key Solutions
Three decisions that separate drivin from taxis and rentals
drivin stands on route sharing, private car borrowing, and the trust layer that makes both possible between strangers.
Dashboard for writers
Outcome
The prototype defines a mobility model built on routes, schedules, and trust
01
Defined a hybrid model combining route sharing and P2P car rental
02
Split the service into Usage Mode and Earning Mode
03
Replaced taxi style dispatch with route-overlap matching
04
Built a car borrowing flow around purpose, time, trust, and vehicle.
05
Added schedule based planning for upcoming rides and rentals
Reflection
A mobility product must be more than fast matching
drivin taught me that local mobility is not only about speed or price. When ordinary people share routes,
seats, or cars, the product's real job is reducing social and operational uncertainty between strangers.
The most important design decision was moving away from taxi-style calling toward route based matching.
It aligned the service with how people already move: commutes, errands, and casual side income,
instead of asking them to behave like on demand drivers.
If developed further, I would validate route matching behavior, simplify verification, and test how much trust information
people need before they feel comfortable sharing mobility with a stranger.
Next project
Trendnow
