Product Requirements Document

Quick Driver

An on-demand driver-hailing platform — customers book a verified professional to drive their own vehicle. This document specifies the Customer app, Partner (Driver) app, and Admin console.

Version 1.0 · DraftDate June 2026Status For reviewClassification Confidential

1. Overview

1.1 Purpose

This document defines the product requirements for Quick Driver, an on-demand driver-hailing platform that connects customers who own vehicles with verified professional drivers. Unlike a ride-hailing service, the customer books a driver to operate the customer's own vehicle. The platform spans three applications: a Customer App, a Partner (Driver) App, and a web-based Admin Console.

1.2 Product vision

To become the most reliable and trusted on-demand driver service by offering instant and scheduled bookings, transparent dynamic pricing, verified drivers, and specialized matching for premium and luxury vehicles — backed by an operations console that gives the business full control over rides, pricing, drivers, and finances.

1.3 Scope

In scope: Customer App, Partner App, and Admin Console covering instant rides, scheduled rides, outstation (one-way and round trip), rentals, and hourly bookings; OTP authentication, Aadhaar KYC, the dynamic surcharge engine, insurance, driver packages, dispatcher tooling, and financial reporting.

Out of scope (v1): Multi-country/multi-currency operations, an in-app vehicle marketplace, and third-party fleet-management integrations beyond defined APIs.

2. Personas

Five primary actors interact with the platform.

PersonaDescriptionPrimary goals
Customer / OwnerOwns a car, needs a professional driver on demand or on schedule.Book quickly, fair price, safe & verified driver, good match for premium cars.
Partner / DriverProfessional driver who accepts ride requests.Steady ride flow, fair payouts, clarity on schedule, easy onboarding.
Fleet OwnerOwns multiple vehicles or employs fleet drivers.Manage fleet drivers, track earnings, assign rides.
DispatcherOps staff who manually assign / manage rides.Resolve unassigned rides, manage rentals & hourly bookings.
Admin / OpsBusiness operator running the platform.Control pricing, monitor finances, manage users & content.

3. Customer App

3.1 Authentication & onboarding

Login and registration use a single unified OTP-based flow on a mobile number, with no password. The OTP is delivered by SMS with auto-read support, configurable expiry (default 5 minutes) and resend cooldown (default 30 seconds); fallback channels (WhatsApp / IVR) are configurable from Admin. New numbers proceed to onboarding; existing numbers go straight to the home screen. A first-launch onboarding carousel communicates the value proposition, how it works, and safety; its content is managed from Admin → Content Management → On Boarding. The profile captures name, optional email, gender, photo, saved addresses, emergency contacts and language preference.

3.2 Vehicle garage

The customer adds one or more vehicles, each with brand, model, type (hatchback / sedan / SUV / luxury), transmission and registration number. Vehicle type drives both matching and pricing at booking time, and luxury vehicles unlock brand-qualified driver matching (§3.6).

3.3 Ride booking — instant & scheduled

Instant booking performs an immediate driver search and assignment from the current location. Scheduled booking lets the customer pick a future date and time; the system reserves a driver and dispatches ahead of the slot, sending reminders to both customer and driver. In either mode the customer selects which garage vehicle the driver will operate.

3.4 Outstation — one-way & round trip

For one-way outstation trips, the fare is the base plus the per-km outstation rate for the full distance, plus the applicable driver allowance and a return-deadhead component as configured. For round trips, the fare accounts for total trip duration, multi-day driver allowance, night charges and waiting time; the return fare is added to the estimate explicitly and shown in the fare breakup. The estimate must itemize base, distance, return-fare addition, allowances, surcharges, taxes and insurance before confirmation.

3.5 Driver schedule feature

Customers can request a specific driver (subject to availability) for recurring or future trips when that driver has published availability. Drivers publish availability windows in the Partner App, and the Customer App surfaces matching slots for scheduling. Recurring schedules (for example a daily office commute) are supported with per-occurrence cancellation.

3.6 Luxury matching (brand + car)

For premium and luxury vehicles, only drivers explicitly qualified for that brand and segment are matched, ensuring competence with high-value cars. Driver profiles carry capability tags — car segment (economy / premium / luxury), eligible brands (e.g. BMW, Mercedes, Audi) and transmission expertise. The matching engine filters the candidate pool by the booked vehicle's brand and segment before ranking by proximity and rating. If no qualified luxury driver is available, the customer is offered a scheduled slot rather than a mismatched instant assignment.

3.7 Trip lifecycle, payments & support

The customer sees live tracking of driver arrival and trip progress with ETA. Payment supports in-app methods (UPI, cards, wallet) and cash, configurable in Admin → Payment Methods, with coupons applied at checkout. After the trip the customer rates the driver and receives a receipt with the full fare breakup including insurance and surcharges. An SOS control is available during the ride, along with trip history and re-book.

4. Partner (Driver) App

4.1 Onboarding & Aadhaar verification

Driver KYC is performed via Aadhaar online verification (OTP-based eKYC / DigiLocker integration) during onboarding. Additional documents are captured and verified: driving licence, address proof, profile photo, and police clearance where required. Verification status (Pending / Verified / Rejected) is tracked in Admin → Settings → Driver Documents, and a driver cannot go live until verified.

4.2 Preferred assignment escalation

When a ride request is not accepted within the first dispatch window, the system escalates to guarantee fulfilment. Tier 1 offers the request to the nearest eligible drivers. If unaccepted, Tier 2 broadens to preferred / higher-incentive drivers and an increased radius. If still unaccepted, Tier 3 routes the request to the Dispatcher for manual assignment from the Admin console. Escalation timers and incentive bumps are configurable from Admin.

4.3 Driver packages

Drivers subscribe to packages (for example daily, weekly, commission-based, or zero-commission subscription). Packages define the commission rate, payout rules and ride-access privileges, and are managed from Admin → Business Setup → Subscription Plan. The driver wallet shows earnings, package status and renewal.

4.4 Before-start & after-start vehicle video

To document vehicle condition and protect both parties, the driver records a short walk-around video at two checkpoints. The before-start video is mandatory, timestamped and geo-tagged, and recorded before the trip begins; the trip cannot transition to In-Progress until it is captured (configurable enforcement). The after-start / end video is recorded at completion to capture final condition. Both are uploaded and linked to the trip record for dispute resolution and insurance claims, with a configurable retention period.

5. Admin Console

The Admin Console is the web-based operations and configuration hub, organized as a grouped left-sidebar navigation.

5.1 Navigation structure

CategoryItems
DashboardMain landing page with KPIs and metrics.
Access ManagementAccess Control, Live Tracking.
Rides & Service ManagementInstant Ride Bookings, Rental Bookings, Hourly Driver Bookings, Website Bookings.
Dispatcher ManagementDispatcher Rides, Dispatcher Rental, Dispatcher Hourly.
Users ManagementCustomers, Drivers.
Owner ManagementOwners, Fleet Drivers.
Business SetupInstant Ride Package, Rental Packages, Hourly Package, Subscription Plan.
Customer SupportSupport, SOS, Notification.
Content ManagementBanners, On Boarding, CMS Pages.
Site ManagementLanding Page Template, Terms & Conditions, Privacy Policy.
Reports ManagementUser Reports, Driver Reports, Travel Reports.
Settings & ConfigurationsGeneral Settings, Zones, Tax Settings, Coupons, Business Model Settings, Email Template Settings, Payment Methods, Driver Documents.
Payment ManagementPayouts, settlements, commission ledger, refunds, reconciliation.

5.2 Dashboard metrics

The dashboard surfaces total and today's figures across operations and finance: trip volume (Total Trips and Today's Trips); user & driver stats (active counts for Users, Individual Drivers, Owners and Fleet Drivers); financial summaries (Total Earnings and Admin Commission, each categorized by Ride and Rental); and trip status trackers (Completed, Confirmed and Cancelled trips).

6. Dynamic Surcharge Engine

A configurable multiplier engine adjusts fares in real time based on environmental and demand conditions. All factors are managed from Admin and shown transparently to the customer at estimate time, with a maximum combined multiplier to protect customers. See the engine recompute a fare live in the demo →

FactorTriggerBehaviour
Weather / RainWeather API flags rain in the zone, or admin manual toggle.Applies a rain multiplier to base fare for affected zones.
Demand spikeLive demand-to-supply ratio exceeds threshold.Tiered surge multiplier scales with the ratio.
Festival / EventAdmin-scheduled event windows.Applies an event multiplier for the configured window & zone.
Night chargeTrip within configured night hours.Fixed or percentage night surcharge.
InsurancePer-trip coverage (bundled or opt-in per config).Premium shown as a line item; certificate stored on the trip.

Multiple factors combine per a configurable rule and are capped at a maximum total multiplier. The customer always sees a clear surge indicator and the reason before confirming.

7. Ride Status Model

StatusMeaning
RequestedCustomer submitted; searching for a driver.
ConfirmedDriver assigned / accepted (instant or scheduled).
ArrivedDriver at pickup; before-start video pending.
In-ProgressTrip ongoing after before-start video captured.
CompletedTrip ended; after-start video captured; payment settled.
CancelledCancelled by customer, driver or system, per cancellation policy.

8. Non-Functional Requirements

Performance

Driver-matching response under 5 seconds for instant rides; dashboard widgets load under 2 seconds.

Scalability

Handle peak surge windows (festivals / events) with horizontal scaling of matching and pricing services.

Security & privacy

OTP auth, encrypted PII, masked calling, secure storage of KYC and trip videos, and role-based access control for admin.

Reliability

99.9% uptime target, with graceful degradation of surge inputs (e.g. weather API outage falls back to manual control).

Compliance

Aadhaar eKYC handling per UIDAI norms; insurance and tax compliance per jurisdiction.

Observability

Audit logs for fare changes, surcharge application and admin actions.

9. Open Questions

  1. Confirm the insurance model — bundled into every fare versus opt-in line item.
  2. Define the maximum combined surcharge multiplier cap.
  3. Confirm the Aadhaar verification provider (DigiLocker vs. a licensed KYC vendor).
  4. Define payout cadence and settlement cycle for drivers and fleet owners.
  5. Confirm which booking types launch in v1 versus later phases (hourly, rental).
Interactive demo

One app, three sides.

The real customer prototype, a matching partner (driver) app, and the admin console — all one codebase, one design language. Switch between them and click through.

Delivery timeline

A proposed 16-week build.

Four phases across three tracks, on a week scale. Each feature flows User Flow → Design → Frontend → Backend, staggered so design and build pipeline cleanly.

Customer App Partner App Admin Console Cross-cutting Milestone
Weeks 1–5

Phase 1 · Foundation & Customer App

Architecture, OTP auth, vehicle garage, instant/scheduled booking, outstation fares and the surge engine.

Weeks 6–9

Phase 2 · Partner App

Aadhaar onboarding, tiered assignment, before/after video, driver packages & wallet.

Weeks 10–13

Phase 3 · Admin Console

Dashboard, rides & dispatch, business setup, reports, content and payments.

Weeks 14–16

Phase 4 · Edge Cases & Handoff

Insurance, coupons, zones, SOS, hardening (QA · load · security), UAT & documentation.

Technology

One stack, three surfaces.

A TypeScript-first architecture: React Native for the mobile apps, Next.js for the web, and NestJS powering a shared backend. One language end to end, one API for every client.

Mobile apps

React Native

Customer & Partner apps from a single codebase — iOS + Android. Shared components, native performance, OTA updates.

  • Expo / RN with TypeScript
  • Maps, live tracking, camera (KYC & trip video)
  • Push notifications & deep links
  • Shared design system across both apps
Web & admin

Next.js

Marketing site, web bookings, and the full Admin console — SSR for SEO, fast dashboards, role-based access.

  • React + TypeScript, App Router
  • Admin console & dispatcher tooling
  • SSR/ISR landing & CMS pages
  • Server actions + API routes where useful
Backend

NestJS

One modular API serving every client — auth, rides, matching, pricing, payments and the surge engine.

  • Node + TypeScript, modular architecture
  • REST + WebSockets (live tracking, dispatch)
  • Surge engine, matching & dispatch services
  • Aadhaar eKYC, payments & webhooks

System architecture

Customer AppReact Native
Partner AppReact Native
HTTPS · WebSocket
API GatewayAuth · rate limiting · routing
NestJS services
Auth & OTP
KYC / Aadhaar
Rides & Booking
Matching & Dispatch
Surge & Pricing
Payments & Payouts
Notifications
Reports
PostgreSQLCore data
RedisCache · geo · queues
Object storageKYC & trip video

Supporting stack

Data

PostgreSQL (primary), Redis for caching, geo-queries & job queues, PostGIS for location.

Maps & location

Google Maps for routing, ETAs, live tracking and fare distance.

Payments

UPI, cards & wallet via Razorpay with webhooks & settlements.

Identity / KYC

Aadhaar eKYC via DigiLocker or a licensed KYC vendor; document storage encrypted.

Infra & DevOps

Containerized (Docker) on AWS/GCP, CI/CD pipelines, autoscaling for surge windows.

Observability

Centralized logging, metrics & alerting; audit logs for fares, surge & admin actions.

Why this stack

TypeScript end to end

One language across mobile, web and backend — shared types and validation, fewer integration bugs, a team that moves between layers easily.

Maximum code reuse

React Native shares logic across both apps; Next.js and the apps consume the same NestJS API and the same shared types — build once, serve everywhere.

Modular & scalable

NestJS's modular structure lets matching, pricing and payments scale independently — critical for festival and surge peaks.

Hiring & ecosystem

React, Node and TypeScript are among the most widely-adopted tools — a deep talent pool and mature libraries for everything from maps to payments.