Food Delivery Web Application using MERN Stack (FoodRush)

A food delivery app looks like a menu on a screen, but underneath it is a coordination problem between three parties. The customer expects to know exactly where their order stands; the restaurant needs a reliable queue of incoming orders with preparation times; the platform must record every state change and settle commissions accurately. If statuses go stale or an order is lost between "preparing" and "delivered," the marketplace loses trust. Most student builds stop at a menu and a cart — a single-user CRUD app in a food-delivery costume. This project builds the part that matters: a live order lifecycle from placed to delivered, with every transition pushed to the customer's screen in real time, role-separated portals for customers, restaurant partners and admins, and a commission model that shows how the platform earns.

1. A customer searches or browses restaurants, opens a menu and adds items (with customizations) to the cart.
2. At checkout the customer confirms the address; the order is created in "Placed" state and pushed to the restaurant partner's panel in real time.
3. The restaurant accepts the order and sets a preparation time; the customer sees the status change instantly via WebSocket events.
4. As the kitchen works, statuses advance — Preparing → Ready for pickup → On the way → Delivered — each broadcast live to the tracking screen with timestamps.
5. Payment (test-mode gateway or cash-on-delivery) is recorded against the order; the admin dashboard tracks the commission split between platform and restaurant.
6. After delivery, the customer rates the restaurant; reviews feed back into the restaurant's listing score.

Restaurant discovery: listings with cuisines, ratings, delivery time, distance and search/filters
Menu browsing with categories, veg/non-veg markers, item customization (addons, sizes) and photos
Cart with multi-item totals, GST breakup, delivery fee and promo-code support
Order placement with address selection and live order-status tracking (WebSocket push)
Restaurant partner panel: menu CRUD, item availability toggle, incoming-order queue, accept/reject, preparation-time estimates, earnings summary
Admin dashboard: restaurant onboarding/approval, user management, commission settings, order monitoring, payout reports, banner/promotion control
Role-based logins: customer, restaurant partner, delivery-agent (basic) and admin
Ratings and reviews for restaurants and delivery experience
Notifications: order confirmations and status changes (in-app + email/SMS hooks)
Responsive design with a mobile-first ordering flow

Full source code (React frontend + Node/Express backend), commented
Database seed scripts with demo restaurants, menus, users and orders across all roles
Project report PDF (synopsis, ER diagram, DFD, system design, order state machine, testing, conclusion)
PPT presentation
Viva Q&A document (WebSockets, three-sided marketplace design, schema questions)
Deployment guide (localhost, Render/VPS, environment variables, map API key setup)

FAQs

1. What makes this more than a menu-and-cart app? The live order lifecycle: an order moves through placed, confirmed, preparing, ready, picked up, on the way and delivered, with every transition pushed to the customer over WebSockets — plus role-separated portals and a commission model. That is the actual system design of a food-delivery marketplace.
2. How does the live order tracking work? The backend emits Socket.io events on every status change; the customer's tracking screen and the restaurant panel subscribe to the order's room and update instantly, with an audit history of every transition.
3. What demo credentials are included? Seeded logins for a customer, a restaurant partner, a delivery agent and an admin, with demo restaurants and full menus — the entire lifecycle can be run live.
4. Can it be customized for a city or cuisine? Yes — restaurants, menus, delivery zones and commission rates are all data-driven, and the report documents the schema.
5. How is it deployed for a demo? The guide covers localhost, Render and VPS deployment with PM2, MongoDB Atlas setup and environment variables; a phone hotspot is enough for demo-day networking.
6. What would a production version need? KYC-verified restaurant onboarding, a live payment gateway, and real-time GPS courier tracking (the current delivery-agent flow is status-based) — all documented as extensions.

Delivery-agent tracking is a basic status flow; real-time GPS courier tracking on a map is an optional extension.
Payments use a test-mode gateway or cash-on-delivery — going live needs your own gateway account.
Maps integration needs your own (free-tier) API key; the guide walks through key creation.
Seeded demo data covers a handful of restaurants; bulk catalog import is documented but manual.