Food delivery MERN project: orders, partners, and status flow

Food delivery is the project students name when they want something that “looks like a real app.” That ambition is useful — and dangerous. Panels have ordered from Swiggy. They know what live map tracking looks like. If your demo only has a status dropdown and you claim GPS fleet routing, the viva turns hostile quickly.

This guide frames a submission-ready multi-sided food delivery platform: customers browse restaurants and menus, cart and checkout, track an order status timeline; restaurant partners manage dishes and accept orders; admins oversee the marketplace. It matches themes like Food Delivery Platform. Pair with Razorpay MERN ecommerce viva, restaurant management guide (in-house ops vs marketplace), and JWT auth.

Opening pitch (35 seconds)

“Our project is a MERN food delivery marketplace. Customers discover restaurants, build a cart, pay, and track order status from placed through delivered. Restaurant partners manage their own menus and accept or reject incoming orders. Admins moderate restaurants and view platform activity. Payable amounts are recomputed on the server from menu prices. Live lat-long courier GPS is out of scope; we ship a clear status timeline instead.”

Then demo the happy path in under four minutes.

Marketplace vs single restaurant — say which you built

| Model | Who owns the menu | Typical viva angle | | --- | --- | --- | | Single restaurant (POS) | One kitchen | Table sync, kitchen queue — see restaurant guide | | Food delivery marketplace | Many restaurant partners | Discovery, cart across one restaurant, partner dashboard, platform admin |

Do not mix claims. If customers pick from many restaurants, you built a marketplace. If only one brand’s menu exists, call it a restaurant + delivery status demo and stay honest.

Roles and trust boundaries

| Role | Can do | Must not do | | --- | --- | --- | | Customer | Browse, cart, checkout, track own orders | Edit another user’s address book, change menu prices, accept partner orders | | Restaurant partner | CRUD own menu, accept/reject/advance own orders | See other restaurants’ revenue, alter platform fees without admin | | Admin | Approve restaurants, disable listings, overview metrics | Needlessly hold every kitchen action if partners exist |

Q: Where is authorization enforced?
A: JWT + role middleware on Express routes. Partner routes also check restaurantId ownership: order.restaurantId === req.user.restaurantId. UI hiding is not security.

Same pattern as Library Management RBAC — different domain, same discipline (RBAC viva notes).

Core domain model (whiteboard this)

• ▸User — role, optional restaurantId for partners
• ▸Restaurant — name, cuisine tags, isOpen, isApproved
• ▸MenuItem — restaurantId, name, price, isAvailable
• ▸Cart — client-side or server draft; items reference menuItemId + qty
• ▸Order — customerId, restaurantId, lineItems[] with price snapshots, address, payment refs, status, timestamps
• ▸Payment — gateway order id, signature verification flags

Embedded line items on the order beat fragile joins for viva explanations: once placed, yesterday’s paneer price must not change when the partner edits today’s menu.

Cart and server-side totals (non-negotiable)

Attack students forget: DevTools edits price: 1 on the checkout POST.

Defense:

1. ▸Client sends { restaurantId, items: [{ menuItemId, qty }], addressId }.
2. ▸Server loads each MenuItem, verifies same restaurant, isAvailable, multiplies DB price × qty.
3. ▸Adds delivery fee / taxes per your config.
4. ▸Persists snapshots on the order.
5. ▸Creates payment order for that server total only.

Optional live proof in viva: tamper the payload; bill stays correct or request fails validation. This is the same story as restaurant and hotel pricing — examiners love hearing it twice across projects.

Order status machine

Define allowed transitions in one table and enforce on the server:

Example: placed → accepted → preparing → out_for_delivery → delivered, plus cancelled / rejected from early states.

| From | To | Who | | --- | --- | --- | | placed | accepted / rejected | partner | | accepted | preparing | partner | | preparing | out_for_delivery | partner (or delivery role if you have one) | | out_for_delivery | delivered | partner / delivery | | placed / accepted | cancelled | policy: customer or partner |

Reject illegal jumps (placed → delivered). Diagram in Chapter 4. Polling every 10–30s on the tracking page is fine for college labs; WebSockets are future work unless you actually built them.

What to say about “real-time tracking”

Good: “Status timeline with timestamps; customer refreshes or polls.”
Bad: “Live GPS like Swiggy” without a map SDK, courier app, and location pings.

If asked about maps: “Optional extension using Map APIs; our contribution is marketplace workflow and payment integrity.”

Discovery and cart rules that sound product-aware

• ▸Filter restaurants by cuisine / open now / approved.
• ▸Cart usually locked to one restaurant per order (clear the cart or warn when switching). Multi-restaurant carts are a harder product; undergrad scope prefers one restaurant per checkout.
• ▸Out-of-stock: isAvailable: false hides or blocks add-to-cart; server rechecks at place-order time.

Q: Can I order from two restaurants in one payment?
A: Not in our scope — one restaurant per order simplifies partner acceptance and delivery fee logic.

Payments with Razorpay (or similar)

Flow students should narrate:

1. ▸Server creates Razorpay order with server-computed amount (paise).
2. ▸Client opens checkout with that order id.
3. ▸On success, client sends payment id + signature.
4. ▸Server verifies signature; marks order paid; only then partner sees it as payable work (or you allow COD — say which).

Never mark paid because the client said so. Details and viva traps: Razorpay MERN ecommerce viva. Sibling storefronts on the hub: MERN E-Commerce, Multi-Vendor Marketplace.

COD vs prepaid

If you support COD, status can reach placed without gateway verification; document fraud risk as a limitation. Prepaid is cleaner for demos.

Partner dashboard demo gold

1. ▸Login as partner for “Spice Route.”
2. ▸Show menu list; toggle one item unavailable.
3. ▸As customer, try to add it — blocked.
4. ▸Place a valid order as customer.
5. ▸Partner accepts → preparing → out_for_delivery → delivered.
6. ▸Customer tracking page reflects each step.
7. ▸Admin view: list restaurants / open orders (even a table is enough).

Seed at least two restaurants, ten dishes, customer + partner + admin. Empty marketplaces fail demos — seed data guide.

Differentiation that is honest

Campus-safe customizations:

• ▸College / city branding; INR prices; Indian cuisine seed data
• ▸Restaurant open hours validation
• ▸Simple coupon: fixed ₹50 off if subtotal > ₹299 (server-side)
• ▸PDF or printable bill
• ▸Rating stars after delivered (optional)

Avoid claiming ML demand forecasting or drone delivery. Same project differentiate and customize college name apply.

Report chapter mapping

• ▸Ch 1: Problem — fragmented local ordering; scope marketplace vs POS.
• ▸Ch 2: Related systems (Swiggy/Zomato at high level — features, not scraped code).
• ▸Ch 3: Actors, use cases — Browse, Checkout, Accept Order, Track.
• ▸Ch 4: Collections + status diagram + sequence for place-order.
• ▸Ch 5: JWT roles, price recompute, Razorpay verify, partner ownership checks.
• ▸Ch 6: Test cases (table below).
• ▸Ch 7–8: Results screenshots, limitations (no live GPS, single-city assumption).

Slides should show one status diagram and one checkout sequence — not twenty UI clones. 14-slide structure.

Testing table worth defending

| Case | Expected | | --- | --- | | Tampered line price in POST | Server total uses DB prices | | Add item from restaurant B while cart has A | Reject or force clear | | Partner accepts another restaurant’s order | 403 | | Illegal status jump | 400 | | Double payment confirm | Idempotent paid state | | Unapproved restaurant in catalog | Hidden from customers | | Place order for unavailable item | Reject |

Automate what you can; screenshots of failing tampered requests impress panels.

Demo script (about four minutes)

1. ▸Customer browse → open restaurant → add two items → checkout address.
2. ▸Pay (test mode) → land on tracking placed.
3. ▸Switch partner account → accept → preparing.
4. ▸Advance to out_for_delivery → delivered.
5. ▸Optional: show admin restaurant list.
6. ▸One failure: attempt status skip or price tamper narration if time.

Silence during Razorpay popup feels like a crash — narrate “test keys, signature verified server-side.”

Extended Q&A bank

Q: Why Redux Toolkit?
A: Cart and auth client state; server remains source of truth for prices and orders.

Q: Why MongoDB?
A: Restaurant/menu/order documents; flexible line-item snapshots. Index restaurantId, customerId, status.

Q: Delivery fee logic?
A: Flat fee or slab by distance-proxy (pincode). If flat, say flat. Do not invent Haversine if unused.

Q: Inventory of ingredients?
A: Out of scope; isAvailable on finished dishes only.

Q: How is this different from Multi-Vendor Marketplace?
A: Food domain adds restaurant acceptance and delivery status timeline; general marketplace emphasizes catalog/commission. Overlap: multi-seller trust boundaries.

Q: Scalability to city level?
A: Undergrad single deployment; future work: queue workers, geo sharding. Do not claim load tests you did not run.

Q: Food safety / FSSAI?
A: Academic demo; production would need partner KYC and compliance — limitation slide.

Address and delivery-fee edge cases

Customers need at least one saved address (line1, city, pincode, phone). On checkout, bind addressId owned by req.user.id — never accept a raw address blob from another user id.

Delivery fee options that are easy to defend:

• ▸Flat fee (e.g. ₹40) — say so in report.
• ▸Slab by subtotal — free above ₹499.
• ▸Pincode table — small JSON map; still not GPS.

Compute fee on the server after line totals. If the restaurant is marked closed (isOpen: false) or unapproved, reject place-order even if the UI was stale.

Concurrent accept races

Two partner tabs clicking Accept: use a conditional update (status === 'placed') so only one transition wins. Mention optimistic UI only if you handle 409 responses.

Environment and lab-machine notes

Document Node version, Mongo URI, Razorpay test keys in .env.example. Never commit live secrets. For viva hall Wi‑Fi failures, keep a screen recording of the full path as backup — examiners sometimes accept a controlled recording if the live gateway is blocked, but prefer live test-mode payment when possible.

Cold-run checklist the night before: drop local DB → seed → customer order → partner flow → admin glance.

Comparison table for Chapter 2 (keep short)

| System | Similarity | Your academic angle | | --- | --- | --- | | Swiggy / Zomato | Marketplace + status | You omit courier GPS / ads / subscriptions | | Single restaurant POS | Kitchen status | You add multi-restaurant discovery | | Generic ecommerce | Cart + Razorpay | You add partner accept + food status machine |

Cite product categories, not scraped proprietary algorithms.

Week-before-external plan

1. ▸Seed two restaurants with distinct cuisines.
2. ▸Record one tampered-price API failure for Chapter 6.
3. ▸Customize branding (customize guide).
4. ▸Rehearse GPS honesty sentence until it is calm, not apologetic.
5. ▸Align slides with what examiners look for.

Groups: one owner for partner dashboard, one for customer checkout, one for report diagrams — group roles.

Integrity note

If you started from a scaffold or package, list customizations: seed menus, coupon rule, branding, stricter ownership checks. Do not claim you invented JWT or Razorpay. Academic integrity still applies.

Limitations slide (use if true)

• ▸No live courier GPS or rider mobile app
• ▸One restaurant per cart/order
• ▸Test-mode payments
• ▸No kitchen printer / POS hardware
• ▸Single-region demo data

Panels respect bounded Swiggy-shaped scope.

Soft next step after reading

Inspect Food Delivery Platform for Instant / made-to-order options, compare payment viva notes via Razorpay guide, or browse the e-commerce hub. For submission packaging mindset, see submission-ready project package. WhatsApp helps when setup or scope is stuck — rehearse the status machine aloud first.

Sample oral answers (structure, not scripts)

“How does a partner only see their orders?”
“Orders store restaurantId. Partner JWT includes their restaurant. List and mutate endpoints filter and authorize on that id after role check.”

“What if payment succeeds but order insert fails?”
“Prefer creating a pending order, then mark paid after verify — or use an idempotency key on payment id. We document our actual order of operations in Chapter 5 and test double-confirm.”

“Why not Firebase?”
“Express + Mongo keeps authorization logic in one place we can show line-by-line; Firebase is fine elsewhere but not our stack claim.”

Closing rehearsal checklist

• ▸[ ] Explain marketplace roles in 40 seconds
• ▸[ ] State server price recompute without notes
• ▸[ ] Draw status transitions; name illegal jumps
• ▸[ ] Demo partner accept → delivered with tracking
• ▸[ ] Answer GPS question with honest scope
• ▸[ ] Show or describe signature verification step

Takeaway: A food delivery final-year viva is won on multi-role trust boundaries, server-side money, and a believable status machine — not on pretending you shipped Swiggy’s map stack. Build the marketplace loop cleanly, seed it richly, and leave GPS to the limitations slide unless you truly implemented it.