Uber (today’s MVP) — Founder Kit

Overview

Goal: Validate a two-sided rides marketplace in one city with strict scope control and clear unit economics.

• Primary users: Riders, Drivers, Ops Admin
• Platforms: Mobile App (rider), Mobile App (driver) or shared app with roles, Admin web panel
• Payments: Stripe (Connect Express) for payouts
• Risk controls: Driver KYC, background checks (stub), phone/email verification

MVP Scope (must-have)

• Auth: email or phone OTP for riders & drivers
• Driver onboarding: profile, vehicle, license/KYC upload (stubbed provider), availability toggle
• Rider request flow: pickup/dropoff, fare quote (distance+time estimator), request/accept, live status
• Dispatch: simple nearest-available driver assignment (radius + FIFO)
• Trip lifecycle: requested → accepted → picked up → in-progress → completed → rated
• Payments: rider pay on complete; driver weekly payouts (Stripe Connect Express)
• Ops dashboard (read-only v1): users, trips, payouts, flags

Key Screens (rider)

1. Map + Search: set pickup & dropoff, see ETA & price estimate
2. Request: confirm quote, payment method, place request
3. Live Trip: driver location, arrival ETA, contact driver (masked)
4. Receipt & Rating: price breakdown, rate driver

Key Screens (driver)

1. Availability toggle + queue: go online/offline
2. Incoming request: pickup ETA, fare, accept/decline
3. In-trip: navigate pickup, start trip, end trip
4. Earnings: weekly payout summary

Data Model (starter)

User { id, role[rider|driver|admin], name, email, phone, rating, createdAt }
DriverProfile { userId(FK), vehicleMake, vehicleModel, plate, licenseDocUrl, kycStatus }
PaymentMethod { id, userId(FK), provider[stripe], token, last4 }
Trip {
  id, riderId(FK), driverId(FK|null), status[req|acc|pick|inprog|done|cancel],
  pickupLat, pickupLng, dropLat, dropLng,
  estimateFare, finalFare, distanceKm, durationMin,
  requestedAt, acceptedAt, startedAt, completedAt
}
Payout { id, driverId(FK), amount, periodStart, periodEnd, status[pending|paid], providerRef }
Flag { id, userId(FK), tripId(FK|null), reason, note, createdAt }

API (v1 outline)

POST   /auth/otp/request         → { phone/email }
POST   /auth/otp/verify          → session

GET    /drivers/me               → driver profile
POST   /drivers/me               → update profile, docs, availability

POST   /rider/quote              → { pickup, dropoff } → { estimateFare, etaMin }
POST   /rider/request            → create Trip(req)
WS     /rider/live               → trip status stream

GET    /driver/queue             → next request (poll/WS)
POST   /driver/accept            → Trip(acc)
POST   /trip/start               → Trip(inprog)
POST   /trip/complete            → Trip(done) → charge rider → enqueue payout

GET    /admin/overview           → basic stats (read-only)

Notes: WebSocket (or SSE) channels for live status are ideal, but polling works for MVP. Payments integrate Stripe Checkout/Payment Intents for rider and Connect for driver payouts.

Pricing & Unit Economics (starter)

• Fare = base + (per-km × distance) + (per-min × duration), surge multiplier optional
• Marketplace take rate: 15–25% (MVP default 20%)
• Driver payouts batched weekly to cut fees

GTM (first 30–60 days)

• Start in one dense zone (university or downtown)
• Recruit 50–100 drivers with cash signup bonus (capped) & weekly leaderboards
• Acquire 500 riders via campus groups & local ads; measure request→accept→complete funnel
• Hit reliability > 85% within target radius & time windows

Risks & Mitigations

• Safety/KYC: start with basic doc upload + manual review; upgrade providers later
• Liquidity: constrain geo/time, driver floors, request throttling to protect SLAs
• Regulatory: limited pilot under existing T&C; counsel for expansion