How to Clone DoorDash

Create a full-stack DoorDash-style local food-delivery marketplace called SwiftPlate using Next.js (App Router), Tailwind CSS, Prisma and SQLite (swap to Postgres later).

## What to build
A three-sided marketplace where eaters order from merchants and couriers deliver, scoped to a single city. Platform charges a merchant commission and eater fees, and pays couriers per delivery.

## Key screens
- Eater home: address bar, cuisine filters, grid of nearby open merchant cards (rating, ETA, delivery fee)
- Merchant menu: category sections, item cards, item modal with modifiers and add-to-cart
- Cart & checkout: fee breakdown (subtotal + delivery + service + tip) and Place Order
- Order tracking: status timeline + a map with courier position + ETA
- Merchant dashboard: incoming orders (accept/mark ready) + menu editor
- Courier dashboard: go online, offered deliveries, active delivery steps, earnings
- Auth: email credentials; role chosen at signup (eater/merchant/courier)

## Schema (Prisma)
User (id, name, email, role, isOnline), Merchant (id, ownerId, name, cuisine, address, lat, lng, deliveryRadiusKm, hours Json, rating, isOpen), MenuItem (id, merchantId, category, name, desc, price, photo, modifiers Json, isAvailable), Order (id, eaterId, merchantId, courierId, items Json, subtotal, deliveryFee, serviceFee, tip, total, commission, status, eaterLat, eaterLng), Review (id, orderId, eaterId, rating, comment)

## Logic that must work
- Only list merchants that are open AND within delivery radius of the eater's coordinates (compute distance server-side)
- Price math in one shared util: total = subtotal + deliveryFee + serviceFee + tip; commission = subtotal * rate; reused by UI and API
- Order status state machine: placed → accepted → preparing → ready → picked_up → delivered (or cancelled); enforce valid transitions server-side
- When an order is marked ready, it becomes available to online couriers; a courier accepting it sets courierId and prevents others from taking it
- Handle the no-courier-available case: keep a ready order in a queue until someone accepts
- A courier can hold only one active (non-delivered) order at a time
- Merchant payout = subtotal - commission; courier earns a base fee + tip; the platform keeps commission + service fee
- Reviews allowed only after an order is delivered; one review per order

## Style
Appetizing: white canvas, red/orange (#EB1700) primary, rounded-xl cards with food images, clear ETA + fee labels, Inter font, skeleton loaders. Mobile-first - cart is a sticky bottom bar; tracking is a full-screen map.

Seed with 8 merchants (varied cuisines, full menus with modifiers), 2 couriers, 3 eaters, and several orders across different statuses. Use Stripe test mode for checkout if available; otherwise mock payment with a fake card form that always succeeds.

You are building a production-quality DoorDash clone scoped to one city. Work iteratively: scaffold, then implement feature by feature, running the app after each step.

## Stack
- Next.js 14 App Router, TypeScript, Tailwind CSS, shadcn/ui
- PostgreSQL + PostGIS via Prisma; Supabase for auth (email + Google), storage and Realtime
- Stripe Connect (separate charges & transfers) to split one charge into merchant payout, courier payout and platform fee
- Mapbox for geocoding, routing and the tracking map; BullMQ (Redis) for the dispatch/offer queue; Zod for all validation

## Architecture requirements
- Three role-scoped app areas (eater, merchant, courier) in route groups sharing components; middleware enforces role access
- The order lifecycle is a server-enforced state machine in lib/orders.ts: placed → accepted → preparing → ready → offered → picked_up → delivered | cancelled. Never advance from the client
- Dispatch is a queue-driven worker, not a request handler: on 'ready', enqueue an offer to the nearest online courier (PostGIS nearest-neighbor); on decline/timeout, re-offer to the next. One active delivery per courier
- lib/pricing.ts is the single source of truth for total and the multi-party split (merchant payout = subtotal - commission; courier pay = base + tip; platform keeps commission + service fee). Recompute server-side; never trust the client

## Data model
users, merchants (geography point, hours jsonb), menu_items (modifiers jsonb), orders (status enum, items jsonb, geo points), delivery_offers (order_id, courier_id, status, expires_at), reviews, payouts. GiST index on merchant/courier locations; index orders(status), orders(merchant_id).

## Implementation order
1. Scaffold + Prisma schema (+ PostGIS) + Supabase auth with role-based middleware
2. Merchant side: profile, hours, delivery zone, menu CRUD with modifiers and photo upload
3. Eater discovery: geocode the address, PostGIS query for open in-range merchants, menu + cart with modifier pricing
4. Checkout: Stripe PaymentIntent; create the order; compute and persist the multi-party split; webhook confirms
5. Merchant order queue: accept → preparing → ready transitions driving the dispatch enqueue
6. Dispatch worker + courier app: offer to nearest online courier with timeout/re-offer, accept locks the order, pickup/dropoff steps, mark delivered
7. Realtime tracking: courier location channel feeding the eater's map + ETA; Supabase Realtime on order status
8. Payouts (Stripe transfers to merchant and courier), ratings, and a refund/support flow

## Quality bar
- loading.tsx skeletons and error.tsx boundaries; optimistic UI on status actions with server reconciliation
- Currency in integer cents formatted with Intl.NumberFormat; the payment split must always reconcile to the charge
- Handle the unhappy paths explicitly: no courier accepts, merchant rejects, eater cancels before pickup
- Seed script: 1 city, 8 merchants with full menus, 4 couriers, 5 eaters, 20 orders across all statuses

Start with step 1. After each step, tell me what to verify in the browser before moving on. Flag honestly where realtime dispatch needs a persistent worker rather than serverless functions.

Design the complete UI for a DoorDash-style local delivery marketplace called SwiftPlate. React + Tailwind, shadcn/ui components, lucide-react icons. Appetizing, trustworthy aesthetic: white background, warm red/orange (#EB1700) primary, rounded-xl cards with food imagery, clear ETA and fee labels, Inter font. Mobile-first - design phone layouts first, then desktop.

## Screens to generate

### 1. Eater home
- Top bar: delivery address selector (pin icon + 'Deliver to ...'), search, cart icon with badge
- Cuisine filter chips row (Pizza, Sushi, Burgers, Healthy, Mexican, Dessert) with active state
- Merchant card list: cover photo, logo badge, name, rating · (reviews), '$X delivery · 20–30 min' meta, a promo tag on some

### 2. Merchant menu
- Sticky header with cover image, name, rating, hours and a back button
- Category nav (Popular, Mains, Sides, Drinks) that scrolls to sections
- Item rows: name, description, price, thumbnail; tapping opens a modifier modal (radio option groups, quantity stepper, Add to cart $X)
- Sticky bottom 'View cart (3) · $X' bar

### 3. Cart & checkout
- Editable line items with quantity steppers
- Fee breakdown card: subtotal, delivery fee, service fee, tip selector (chips: 15% / 18% / 20% / custom), total in bold
- Address and payment summary rows; a big 'Place order' button

### 4. Order tracking
- Full-screen map with a moving courier marker and the route
- Bottom sheet: status stepper (Order placed → Preparing → On the way → Delivered) with an ETA headline, courier card (avatar, name, vehicle), and a contact button

### 5. Courier dashboard
- Online/offline toggle header with today's earnings
- Offered delivery card: pickup → dropoff, distance, estimated pay, an Accept button with a countdown ring
- Active delivery view: map, step card (Go to merchant → Confirm pickup → Deliver → Complete)

### 6. Merchant dashboard
- Incoming orders column with order cards (items, total, timer) and Accept / Mark ready buttons
- A menu editor preview: category list with item rows and availability toggles

Make every screen fully responsive, optimizing for mobile. Use realistic placeholder data - real-sounding restaurant names, item prices $4–$24, delivery fees $0–$5.99, ETAs 15–40 min, ratings 4.3–4.9.

Build a local food-delivery marketplace app (DoorDash model) called SwiftPlate, scoped to one city.

## Entities
- Merchant: name, cuisine, address, lat, lng, deliveryRadiusKm (number), hours (JSON), rating (number), isOpen (boolean), owner (user reference)
- MenuItem: merchant (reference), category, name, description, price (number), photo (image), modifiers (JSON: option groups), isAvailable (boolean)
- Order: eater (user), merchant (reference), courier (user), items (JSON), subtotal, deliveryFee, serviceFee, tip, total, commission, status (placed/accepted/preparing/ready/picked_up/delivered/cancelled), eaterLat, eaterLng, createdAt
- Review: order (reference), eater (user), rating (1–5), comment, createdAt

## Roles & permissions
- Roles: eater, merchant, courier, admin (set at signup)
- Merchants edit only their own menu and see only their own orders
- Couriers see offered/active deliveries assigned to them; eaters see only their own orders
- Admin: manage merchants, view all orders and a revenue dashboard (commission + fees by day)

## Pages
1. Eater home: address + cuisine filters, list of nearby open merchants (rating, ETA, delivery fee)
2. Merchant menu: categories and items, item modal with modifiers, add to cart
3. Cart & checkout: fee breakdown (subtotal + delivery + service + tip), place order
4. Order tracking: status timeline + map with courier position + ETA
5. Merchant dashboard: incoming orders (accept/mark ready), menu editor with availability toggles, hours
6. Courier dashboard: online toggle, offered deliveries with pay/distance, active delivery steps, earnings
7. Admin dashboard: merchants, live orders, daily revenue chart

## Rules
- Only show merchants that are open and within deliveryRadiusKm of the eater's location
- total = subtotal + deliveryFee + serviceFee + tip; commission = a percentage of subtotal deducted from the merchant payout
- Order status advances placed → accepted → preparing → ready → picked_up → delivered; when ready, it's offered to online couriers; the first to accept is assigned
- A courier may hold only one active (non-delivered) order at a time; reviews allowed only after delivery

## Look & feel
DoorDash-inspired: white background, warm red/orange (#EB1700) primary buttons, food-photo cards with rounded corners, clear ETA and fee labels, clean sans-serif typography. Mobile responsive throughout - this is a phone-first experience.

Seed with 8 merchants of varied cuisines, full menus with modifiers, 2 couriers, 3 eaters, and several orders in different statuses so every dashboard has data.