Ridesharing App Development
Budget: $10 – $30 USD
Ridesharing App
1. Objective
Build a lightweight ridesharing mobile app that supports:
1. Passenger-first shared trip (A→B created by first passenger)
2. Driver-first trip listing (driver publishes A→B)
3. On-demand private ride (taxi-style)
Users must choose role during signup:
• Passenger
• Driver
Roles remain separate after signup (no mixed UI).
________________________________________
2. User Roles & Access Control
2.1 Roles
• Passenger
• Driver
User must select role during signup. Role determines available features and screens.
Acceptance Criteria
• On first launch, user sees role selection: “Register as Passenger” or “Register as Driver”.
• After signup, only role-specific dashboard is shown.
• Passenger cannot access driver screens.
• Driver cannot access passenger booking screens.
• Role is stored permanently in user profile.
________________________________________
3. Signup & Authentication Flow
3.1 Signup Steps
1. Enter phone number
2. Verify OTP
3. Enter name
4. Select gender
5. Select role (Passenger / Driver)
If Driver selected:
• Upload vehicle details
• Upload license
Acceptance Criteria
• OTP verification required before proceeding.
• Gender selection mandatory (MALE / FEMALE).
• Role selection mandatory before account creation.
• Driver must upload:
o Vehicle type
o Plate number
o License image
o Year
• Passenger signup does not require vehicle details.
________________________________________
4. Core Modes Supported
4.1 Passenger-First Shared Trip
Passenger creates route A→B and other passengers join along the path.
4.2 Driver-First Trip Listing
Driver publishes route A→B with seats and fare; passengers join.
4.3 On-Demand Private Ride
Passenger requests ride; nearest driver is matched.
________________________________________
5. Core Data Models
5.1 User
Fields:
• id
• name
• phone
• gender
• role (PASSENGER | DRIVER)
• rating
Acceptance Criteria
• Role stored and immutable after signup (unless admin changes).
• Gender must be used for filtering rides.
________________________________________
5.2 Trip
Fields:
• tripId
• mode (PASSENGER_FIRST | DRIVER_FIRST | ON_DEMAND)
• origin (lat,lng)
• destination (lat,lng)
• routePath (polyline)
• baseFare
• seatsTotal
• seatsAvailable
• genderPreference
• driverId (nullable)
• passengers list
• status (OPEN | MATCHING | CONFIRMED | STARTED | COMPLETED)
Acceptance Criteria
• Trip must store route path.
• Seats-available decreases when passenger joins.
• Trip status updates in correct lifecycle order.
________________________________________
5.3 Passenger Segment
Fields:
• userId
• pickup
• dropoff
• calculatedFare
Acceptance Criteria
• Fare must be calculated proportional to traveled segment.
• Each passenger record linked to a trip.
• For security purposes, the Photo of passenger and driver should be shared upon joining.
________________________________________
6. Passenger Features
6.1 Create Shared Trip (Passenger-First)
Passenger inputs:
• Departure (A)
• Destination (B)
• Gender preference (optional)
System creates trip with mode PASSENGER_FIRST.
Acceptance Criteria
• Trip appears publicly in “Available Trips”.
• Seats default = 4 (configurable).
• DriverId remains null until driver accepts.
• After Trip Confirmation (joined), Passenger Can See: Driver photo, Driver first name, Vehicle model, Plate number, Driver rating, In-app Call button, In-app Chat, NOT real phone number plus passengers also can see each others’ photo after joining.
________________________________________
6.2 Join Existing Trip
Passenger enters:
• Pickup location
• Dropoff location
System validates:
• Locations lie along route corridor
• Direction matches trip
• Gender preference satisfied
Acceptance Criteria
• Passenger can join only if route overlap exists.
• System shows calculated fare before join.
• After join, seatsAvailable decreases.
• After Trip Confirmation (joined), Passenger Can See: Driver photo, Driver first name, Vehicle model, Plate number, Driver rating, In-app Call button, In-app Chat, NOT real phone number plus passengers also can see each others’ photo after joining.
________________________________________
6.3 On-Demand Ride Request
Passenger enters pickup + destination.
System:
• Finds nearest available driver
• Sends request
• Creates ON_DEMAND trip
Acceptance Criteria
• Nearest driver determined by distance sorting.
• Passenger sees driver details once accepted (photo & phone number).
• Only one passenger per ON_DEMAND trip.
________________________________________
7. Driver Features
7.1 Publish Route Trip (Driver-First)
Driver inputs:
• Origin
• Destination
• Seats
• Base fare
• Gender preference
Trip created with mode DRIVER_FIRST.
Acceptance Criteria
• For both, drivers & passengers, the trip becomes visible to passengers searching along route & at custom radius.
• Driver can edit or cancel before confirmation.
________________________________________
7.2 Accept Passenger-First Trips
Driver sees list of open passenger-created routes and can accept one.
Acceptance Criteria
• Once driver accepts, driverId assigned to trip.
• Trip status changes to CONFIRMED.
________________________________________
7.3 Accept On-Demand Ride
Driver receives nearby ride requests sorted by proximity.
Acceptance Criteria
• Driver must accept within timeout.
• If accepted, trip created with driver assigned.
________________________________________
8. Matching & Route Logic
8.1 Route Corridor Matching
Passenger pickup and drop-off must lie within configurable radius (e.g., 1km) of trip route line. This could be customized by both, passengers and drivers.
Acceptance Criteria
• If pickup or dropoff outside corridor → join rejected.
• System must not require heavy map SDK.
________________________________________
8.2 Direction Matching
Passenger travel direction must align with trip direction.
Acceptance Criteria
• Angle between vectors < 45° allowed.
• Opposite direction requests rejected.
________________________________________
9. Fare Calculation Rules
Fare is proportional to passenger segment distance.
Formula:
fare = baseFare × (segmentDistance / totalRouteDistance)
Acceptance Criteria
• Fare displayed before join confirmation.
• Fare recalculated if route changes.
• Full route passenger pays full baseFare.
________________________________________
10. Sorting Logic
Available vehicles and trips must be sorted by proximity to passenger pickup.
Acceptance Criteria
• Distance computed using Haversine formula.
• Closest trips appear first in list.
________________________________________
11. Gender Preference Enforcement
Trips may define allowed gender.
Acceptance Criteria
• Passenger cannot join trip if gender not allowed.
• Gender filtering applied during search and join.
________________________________________
12. Trip Lifecycle States
States:
OPEN → MATCHING → CONFIRMED → STARTED → COMPLETED
Acceptance Criteria
• State transitions must follow strict order.
• STARTED only when driver begins trip.
• COMPLETED only after final drop-off.
________________________________________
13. UI/UX Screens
Passenger App
1. Role-based dashboard
2. Create Shared Trip
3. Available Trips List (sorted by proximity)
4. Join Trip Preview (shows dynamic fare)
5. Request Private Ride
6. Active Trip Tracking
7. Trip History
Driver App
1. Driver dashboard
2. Publish Route Trip
3. Incoming Passenger-First Trip Requests
4. On-Demand Ride Requests
5. Active Trip Navigation
6. Earnings & Trip History
Acceptance Criteria
• Passenger UI must not show driver-only options.
• Driver UI must not show passenger booking options.
________________________________________
14. Notifications
System must send:
• New passenger joined
• Driver assigned
• Trip confirmed
• Trip started
• Trip completed
Acceptance Criteria
• Push notifications triggered on every state change.
• Users receive only relevant role-based notifications.
________________________________________
15. Edge Case Handling
Case: Passenger outside route
→ Show “No matching shared trips found”.
Case: Seats full
→ Join button disabled.
Case: No driver for passenger-first trip
→ Trip remains open until accepted.
Acceptance Criteria
• System must gracefully handle all edge scenarios.
• No crashes or inconsistent states allowed.
________________________________________
16. Performance Requirements
• Lightweight architecture
• Minimal external SDK usage
• Efficient matching logic
Acceptance Criteria
• Trip search response < 2 seconds.
• Matching logic must run server-side.
• App must support low-bandwidth environments.
________________________________________
17. Final Mandatory Requirements
1. Role selection during signup is required.
2. Roles remain separate with independent dashboards.
3. App supports three ride modes simultaneously.
4. Shared trip joining must use route corridor + direction matching.
5. Fare must be dynamically calculated per passenger segment.
6. Trips must be sorted by proximity to passenger.
7. Gender preference filtering must be enforced.
________________________________________
18. Definition of Done (Global Acceptance Criteria)
The feature is complete when:
• Users can signup with role selection.
• Passenger can create shared trip A→B.
• Other passengers along route can join with correct fare.
• Drivers can publish trips and accept shared routes.
• On-demand rides match nearest driver successfully.
• All flows enforce gender preference, seat limits, and route matching.
• Trips transition correctly through lifecycle states.
• Passenger and Driver apps remain fully separated after signup.
• Other features will be added & necessary changes will be made to the above feature upon client initiation.
1. Objective
Build a lightweight ridesharing mobile app that supports:
1. Passenger-first shared trip (A→B created by first passenger)
2. Driver-first trip listing (driver publishes A→B)
3. On-demand private ride (taxi-style)
Users must choose role during signup:
• Passenger
• Driver
Roles remain separate after signup (no mixed UI).
________________________________________
2. User Roles & Access Control
2.1 Roles
• Passenger
• Driver
User must select role during signup. Role determines available features and screens.
Acceptance Criteria
• On first launch, user sees role selection: “Register as Passenger” or “Register as Driver”.
• After signup, only role-specific dashboard is shown.
• Passenger cannot access driver screens.
• Driver cannot access passenger booking screens.
• Role is stored permanently in user profile.
________________________________________
3. Signup & Authentication Flow
3.1 Signup Steps
1. Enter phone number
2. Verify OTP
3. Enter name
4. Select gender
5. Select role (Passenger / Driver)
If Driver selected:
• Upload vehicle details
• Upload license
Acceptance Criteria
• OTP verification required before proceeding.
• Gender selection mandatory (MALE / FEMALE).
• Role selection mandatory before account creation.
• Driver must upload:
o Vehicle type
o Plate number
o License image
o Year
• Passenger signup does not require vehicle details.
________________________________________
4. Core Modes Supported
4.1 Passenger-First Shared Trip
Passenger creates route A→B and other passengers join along the path.
4.2 Driver-First Trip Listing
Driver publishes route A→B with seats and fare; passengers join.
4.3 On-Demand Private Ride
Passenger requests ride; nearest driver is matched.
________________________________________
5. Core Data Models
5.1 User
Fields:
• id
• name
• phone
• gender
• role (PASSENGER | DRIVER)
• rating
Acceptance Criteria
• Role stored and immutable after signup (unless admin changes).
• Gender must be used for filtering rides.
________________________________________
5.2 Trip
Fields:
• tripId
• mode (PASSENGER_FIRST | DRIVER_FIRST | ON_DEMAND)
• origin (lat,lng)
• destination (lat,lng)
• routePath (polyline)
• baseFare
• seatsTotal
• seatsAvailable
• genderPreference
• driverId (nullable)
• passengers list
• status (OPEN | MATCHING | CONFIRMED | STARTED | COMPLETED)
Acceptance Criteria
• Trip must store route path.
• Seats-available decreases when passenger joins.
• Trip status updates in correct lifecycle order.
________________________________________
5.3 Passenger Segment
Fields:
• userId
• pickup
• dropoff
• calculatedFare
Acceptance Criteria
• Fare must be calculated proportional to traveled segment.
• Each passenger record linked to a trip.
• For security purposes, the Photo of passenger and driver should be shared upon joining.
________________________________________
6. Passenger Features
6.1 Create Shared Trip (Passenger-First)
Passenger inputs:
• Departure (A)
• Destination (B)
• Gender preference (optional)
System creates trip with mode PASSENGER_FIRST.
Acceptance Criteria
• Trip appears publicly in “Available Trips”.
• Seats default = 4 (configurable).
• DriverId remains null until driver accepts.
• After Trip Confirmation (joined), Passenger Can See: Driver photo, Driver first name, Vehicle model, Plate number, Driver rating, In-app Call button, In-app Chat, NOT real phone number plus passengers also can see each others’ photo after joining.
________________________________________
6.2 Join Existing Trip
Passenger enters:
• Pickup location
• Dropoff location
System validates:
• Locations lie along route corridor
• Direction matches trip
• Gender preference satisfied
Acceptance Criteria
• Passenger can join only if route overlap exists.
• System shows calculated fare before join.
• After join, seatsAvailable decreases.
• After Trip Confirmation (joined), Passenger Can See: Driver photo, Driver first name, Vehicle model, Plate number, Driver rating, In-app Call button, In-app Chat, NOT real phone number plus passengers also can see each others’ photo after joining.
________________________________________
6.3 On-Demand Ride Request
Passenger enters pickup + destination.
System:
• Finds nearest available driver
• Sends request
• Creates ON_DEMAND trip
Acceptance Criteria
• Nearest driver determined by distance sorting.
• Passenger sees driver details once accepted (photo & phone number).
• Only one passenger per ON_DEMAND trip.
________________________________________
7. Driver Features
7.1 Publish Route Trip (Driver-First)
Driver inputs:
• Origin
• Destination
• Seats
• Base fare
• Gender preference
Trip created with mode DRIVER_FIRST.
Acceptance Criteria
• For both, drivers & passengers, the trip becomes visible to passengers searching along route & at custom radius.
• Driver can edit or cancel before confirmation.
________________________________________
7.2 Accept Passenger-First Trips
Driver sees list of open passenger-created routes and can accept one.
Acceptance Criteria
• Once driver accepts, driverId assigned to trip.
• Trip status changes to CONFIRMED.
________________________________________
7.3 Accept On-Demand Ride
Driver receives nearby ride requests sorted by proximity.
Acceptance Criteria
• Driver must accept within timeout.
• If accepted, trip created with driver assigned.
________________________________________
8. Matching & Route Logic
8.1 Route Corridor Matching
Passenger pickup and drop-off must lie within configurable radius (e.g., 1km) of trip route line. This could be customized by both, passengers and drivers.
Acceptance Criteria
• If pickup or dropoff outside corridor → join rejected.
• System must not require heavy map SDK.
________________________________________
8.2 Direction Matching
Passenger travel direction must align with trip direction.
Acceptance Criteria
• Angle between vectors < 45° allowed.
• Opposite direction requests rejected.
________________________________________
9. Fare Calculation Rules
Fare is proportional to passenger segment distance.
Formula:
fare = baseFare × (segmentDistance / totalRouteDistance)
Acceptance Criteria
• Fare displayed before join confirmation.
• Fare recalculated if route changes.
• Full route passenger pays full baseFare.
________________________________________
10. Sorting Logic
Available vehicles and trips must be sorted by proximity to passenger pickup.
Acceptance Criteria
• Distance computed using Haversine formula.
• Closest trips appear first in list.
________________________________________
11. Gender Preference Enforcement
Trips may define allowed gender.
Acceptance Criteria
• Passenger cannot join trip if gender not allowed.
• Gender filtering applied during search and join.
________________________________________
12. Trip Lifecycle States
States:
OPEN → MATCHING → CONFIRMED → STARTED → COMPLETED
Acceptance Criteria
• State transitions must follow strict order.
• STARTED only when driver begins trip.
• COMPLETED only after final drop-off.
________________________________________
13. UI/UX Screens
Passenger App
1. Role-based dashboard
2. Create Shared Trip
3. Available Trips List (sorted by proximity)
4. Join Trip Preview (shows dynamic fare)
5. Request Private Ride
6. Active Trip Tracking
7. Trip History
Driver App
1. Driver dashboard
2. Publish Route Trip
3. Incoming Passenger-First Trip Requests
4. On-Demand Ride Requests
5. Active Trip Navigation
6. Earnings & Trip History
Acceptance Criteria
• Passenger UI must not show driver-only options.
• Driver UI must not show passenger booking options.
________________________________________
14. Notifications
System must send:
• New passenger joined
• Driver assigned
• Trip confirmed
• Trip started
• Trip completed
Acceptance Criteria
• Push notifications triggered on every state change.
• Users receive only relevant role-based notifications.
________________________________________
15. Edge Case Handling
Case: Passenger outside route
→ Show “No matching shared trips found”.
Case: Seats full
→ Join button disabled.
Case: No driver for passenger-first trip
→ Trip remains open until accepted.
Acceptance Criteria
• System must gracefully handle all edge scenarios.
• No crashes or inconsistent states allowed.
________________________________________
16. Performance Requirements
• Lightweight architecture
• Minimal external SDK usage
• Efficient matching logic
Acceptance Criteria
• Trip search response < 2 seconds.
• Matching logic must run server-side.
• App must support low-bandwidth environments.
________________________________________
17. Final Mandatory Requirements
1. Role selection during signup is required.
2. Roles remain separate with independent dashboards.
3. App supports three ride modes simultaneously.
4. Shared trip joining must use route corridor + direction matching.
5. Fare must be dynamically calculated per passenger segment.
6. Trips must be sorted by proximity to passenger.
7. Gender preference filtering must be enforced.
________________________________________
18. Definition of Done (Global Acceptance Criteria)
The feature is complete when:
• Users can signup with role selection.
• Passenger can create shared trip A→B.
• Other passengers along route can join with correct fare.
• Drivers can publish trips and accept shared routes.
• On-demand rides match nearest driver successfully.
• All flows enforce gender preference, seat limits, and route matching.
• Trips transition correctly through lifecycle states.
• Passenger and Driver apps remain fully separated after signup.
• Other features will be added & necessary changes will be made to the above feature upon client initiation.