How to Clone Uber

Create an Uber-style local ride marketplace called LiftLocal using Next.js (App Router), Tailwind, Prisma + SQLite. Niche: scheduled small-town and medical-appointment rides.

## What to build
Riders request or schedule rides; approved drivers claim them from a queue; the platform takes 20%. Dispatch is simulated (queue + claim + status machine) - be honest in the UI that GPS positions are mocked.

## Screens
- Landing: rider and driver value props, fare calculator widget, driver sign-up CTA
- Rider booking: address inputs, ride type (standard / accessible / parcel), now-or-scheduled toggle, fare quote computed live as the form changes
- Ride tracking: status stepper updated by polling every 3s, assigned driver card, animated dot on a stylized SVG map, cancel with fee warning
- Ride history with itemized receipts and a post-ride rating modal
- Driver dashboard: online toggle, claimable requests list with a 60s claim countdown, earnings cards (today / this week), scheduled rides
- Driver active-ride screen: advance status buttons (Arrived → Start → Complete), final fare split display
- Admin: rides table with status filter, driver approval queue, manual reassign action, KPI cards (rides today, GMV, platform revenue)

## Prisma schema
User (id, name, email, phone, role, ratingAvg), DriverProfile (userId, vehicleMake, vehicleModel, plate, wheelchairCapable, status, isOnline), Ride (id, riderId, driverId?, type, pickupAddress, dropoffAddress, scheduledFor?, status, fareQuote, fareFinal?, distanceMiles, durationMin, cancellationFee?), RideEvent (rideId, status, createdAt), Rating (rideId, fromUserId, toUserId, stars, tags Json, comment?), Payout (driverId, weekStart, gross, platformFee, net, status)

## Marketplace logic (must actually work)
- Fare engine in one pure function: $3 base + $1.50/mile + $0.35/min, $8 minimum, +$5 accessible, +$2 scheduled; mock distance/duration from address-pair hashing so quotes are deterministic
- Ride status machine: REQUESTED → ASSIGNED → ARRIVING → IN_PROGRESS → COMPLETED (or CANCELLED); enforce legal transitions server-side, write a RideEvent per transition
- Claiming is atomic: two drivers accepting simultaneously must not double-assign (use a conditional update where driverId is null)
- 20% platform fee computed on completion; weekly payout rows aggregate per driver
- Cancellation fee: $0 within 2 minutes of creation, $5 after; driver cancellation re-opens the ride
- Drivers with status != approved cannot go online or claim
- Ratings: post-completion only, one per side per ride; recompute ratingAvg on insert; stars < 3 sets a needsReview flag the admin sees

## API routes
POST /api/rides (create + quote), POST /api/rides/[id]/claim, POST /api/rides/[id]/status, POST /api/rides/[id]/cancel, POST /api/rides/[id]/rate, GET /api/driver/queue, GET /api/admin/rides - all role-checked server-side.

## Style
Professional and calm: navy #0F2A43, amber #F5A623 accents, Inter, soft-shadow cards, status badge colors, mobile-first layouts.

Seed: 8 drivers (6 approved, 2 pending), 5 riders, 25 completed rides across two weeks with ratings, 3 open requests, 2 scheduled rides tomorrow. Include a demo login switcher (rider / driver / admin) so the marketplace can be explored from all three sides.

Build a production-quality ride-booking marketplace (Uber model, niche-scoped to scheduled local and medical transport). The ride lifecycle and money math must be server-authoritative - assume hostile clients on both sides of the marketplace.

## Stack
- Next.js 14 App Router + TypeScript + Tailwind + shadcn/ui; Framer Motion for status transitions
- PostgreSQL via Prisma; NextAuth (email + Google) with role claims (rider / driver / admin)
- Supabase Realtime (or Pusher) channels for live ride-status updates to both parties
- Mapbox GL for map display and geocoding; straight-line-distance fallback so the app runs without an API key

## Core design: the ride is a state machine
Define RideStatus in lib/rides/machine.ts: REQUESTED → ASSIGNED → ARRIVING → IN_PROGRESS → COMPLETED, with CANCELLED reachable from the first three states only. Export canTransition(from, to, actor) - riders can only cancel, drivers can only advance their own assigned rides, admins can force-transition. Every transition writes an append-only ride_events row; the rides.status column is a denormalized cache of the latest event.

## Money (server-authoritative)
- Fare quote: pure function quoteFare(distanceMiles, durationMin, type, scheduled) - $3 base + $1.50/mi + $0.35/min, $8 floor, +$5 accessible, +$2 scheduled. Unit-test the edge cases (minimum fare, rounding to cents)
- Quote is computed and persisted at request time; final fare recomputed at completion from actuals; the client never sends prices
- Platform fee = 20% of final fare; store gross/fee/net on the ride at completion; payouts table aggregates per driver per week (append-only ledger, balances derived)
- Cancellation fees by elapsed time since request (2-minute grace), charged riders only

## Dispatch
- POST /api/rides creates REQUESTED and broadcasts to the drivers:online channel
- POST /api/rides/[id]/claim assigns atomically: UPDATE rides SET driver_id = $me WHERE id = $id AND driver_id IS NULL - return 409 to the loser. Write a concurrency test for this
- Scheduled rides enter the claimable pool 60 minutes before pickup via a cron route
- Unclaimed rides older than 5 minutes appear in an admin 'attention' view with manual assignment
- Be explicit in code comments: real proximity matching needs live driver GPS streams (native background location) - out of scope here; the queue model is the honest web-app equivalent

## Schema
users, driver_profiles (approval status enum, vehicle fields), rides, ride_events, ratings, payouts, saved_places. Indexes: rides(driver_id, status), rides(status, scheduled_for), ride_events(ride_id, created_at).

## Implementation order
1. Schema + auth + role-gated layouts (rider / driver / admin shells)
2. Fare engine with unit tests; booking form with live quote
3. Ride state machine + transition endpoint + ride_events; tracking UI driven by realtime channel
4. Driver queue + atomic claim (with the concurrency test) + active-ride flow
5. Completion math, receipts, ratings, payout ledger
6. Admin board: ride table, driver approvals, force-reassign, KPIs
7. Polish: cancellation fees, scheduled-ride cron, attention queue

## Quality bar
- Every mutation authorized against the actor's role AND ownership of the ride
- Realtime updates degrade gracefully to 3s polling
- Empty states for every dashboard; seed script creates 8 drivers, 5 riders, 30 rides in mixed states

Start with step 1; show me the RideStatus machine and canTransition tests before continuing.

Design the complete UI for a local ride-booking marketplace called LiftLocal (Uber model, scoped to small-town and medical transport). React + Tailwind + shadcn/ui + lucide-react. Aesthetic: calm, trustworthy, operational - deep navy #0F2A43 primary, amber #F5A623 CTAs, Inter font, soft-shadow rounded cards, crisp status-color system (blue assigned, teal in-progress, green completed, red cancelled). Mobile-first throughout.

## Screens

### 1. Rider booking (home)
- Top: greeting + saved-place chips (Home, Work, Clinic) that prefill the form
- Booking card: pickup and destination inputs with location pin icons, ride-type segmented control (Standard / Accessible / Parcel) with small icons, Now vs Schedule toggle revealing a date-time picker
- Fare estimate panel: animated total, expandable line items (base, distance, time, extras), 'Platform fee included' microcopy
- Primary Request Ride button, full-width, amber

### 2. Ride tracking
- Stylized map area (illustrated streets) with pickup pin, destination flag and a vehicle dot moving along a dashed route
- Status stepper: Requested → Assigned → Arriving → In progress → Completed, current step pulsing
- Driver card: photo, name, 4.9 star badge, vehicle + plate chip, call and message icon buttons
- ETA pill ('Arriving in 6 min') and a subdued Cancel link with fee warning modal

### 3. Driver dashboard
- Header: large online/offline switch with status glow, today's earnings stat
- Claimable requests: cards with pickup → dropoff addresses, distance, fare and your-cut amounts, ride-type badge, a 60-second circular countdown and an Accept button
- Tabs: Open requests / My scheduled / History
- Active ride mode: full-screen card with rider info, big sequential action button that changes label (I've arrived → Start ride → Complete ride), fare summary on completion with 80/20 split bar

### 4. Ride history & receipt
- List grouped by day: route summary, fare, status badge, driver avatar
- Receipt detail: itemized fare breakdown table, payment method row, Rebook button
- Rating modal: 5 large stars, tag chips (On time, Clean car, Helpful, Great conversation), optional comment

### 5. Admin dispatch board (desktop)
- KPI row: rides today, gross volume, platform revenue, active drivers
- Rides table: status filter tabs, sortable columns, row actions (view, reassign via driver dropdown)
- Attention rail: unclaimed >5 min requests in amber cards with Assign buttons
- Driver roster: approval queue cards with Approve / Reject, status badges, rating column

### 6. Driver application
- 3-step wizard with progress dots: personal info → vehicle details → documents (upload placeholders) and consent checkbox; success state with 'Under review' illustration

Fully responsive. Fill everything with realistic seed content: 8 drivers, 25 rides across statuses, plausible small-town addresses and fares so every screen demos well.

Build a local ride-booking marketplace (Uber model) called LiftLocal, focused on scheduled small-town rides and non-emergency medical transport.

## Entities
- Ride: rider reference, driver reference (optional until claimed), type (standard/accessible/parcel), pickupAddress, dropoffAddress, scheduledFor (optional), status (requested/assigned/arriving/in_progress/completed/cancelled), fareQuote, fareFinal, distanceMiles, durationMin, cancellationFee
- DriverProfile: user, vehicleMake, vehicleModel, plate, wheelchairCapable, approvalStatus (pending/approved/suspended), isOnline
- RideEvent: ride reference, status, timestamp (append-only history powering the tracker)
- Rating: ride reference, fromUser, toUser, stars, tags, comment
- Payout: driver, weekStart, ridesCount, gross, platformFee, net, status

## Roles
- Rider: books and schedules rides, tracks status, pays the quoted fare, rates drivers
- Driver: applies with vehicle details, goes online, claims open requests, advances ride status, sees earnings (80% of fares)
- Admin: approves/suspends drivers, monitors all rides, manually reassigns stuck requests, sees revenue dashboard

## Pages
1. Rider booking: pickup/destination form with saved places, ride type, now-or-scheduled, live fare quote ($3 base + $1.50/mile + $0.35/min, $8 minimum, +$5 accessible, +$2 scheduled)
2. Ride tracker: status stepper, assigned driver card with vehicle and rating, simulated map position, cancel with fee warning ($5 after a 2-minute grace period)
3. Ride history: receipts with fare breakdown, rebook, post-ride rating modal with tag chips
4. Driver dashboard: online toggle, claimable request queue (first Accept wins, 60-second claim timer), earnings today/this week, scheduled rides
5. Driver active ride: rider contact, sequential status buttons (Arrived → Start → Complete), final fare split shown at completion
6. Driver application: multi-step signup ending in pending-review status
7. Admin board: rides table by status, unclaimed-request alerts after 5 minutes, driver approval queue, daily KPIs (rides, gross, platform revenue)

## Rules
- Platform keeps 20% of every completed fare; drivers keep 80% - both sides always see the split
- A ride can only be claimed once: first approved online driver to accept gets it
- Status must move strictly forward; only riders cancel (with the fee rule), driver cancellations re-open the request
- Scheduled rides become claimable 60 minutes before pickup
- Drivers must be approved before going online; ratings under 3 stars flag them for admin review

## Look & feel
Trust-forward and calm: deep navy #0F2A43, amber #F5A623 call-to-action buttons, Inter font, rounded soft-shadow cards, clear status badge colors. Mobile-first.

Seed: 8 drivers (6 approved, 2 pending - two vehicles wheelchair-capable), 5 riders, 25 completed rides with ratings over two weeks, 3 open requests and 2 scheduled rides for tomorrow so every role's screen looks busy.