Food Delivery Consumer Admin App

Project overview

This food delivery product connected a consumer ordering journey with the operational controls required to prepare, dispatch, and support each order. Customers could discover nearby restaurants, customize menu items, pay securely, and follow delivery status. Administrators managed menus, availability, service zones, live orders, delivery exceptions, promotions, refunds, and performance from a single interface.

I led the application architecture, data model, real-time state design, checkout workflow, admin experience, and production monitoring. The product focused on honest availability and understandable status rather than showing optimistic promises the operation could not meet.

Problem statement

The initial process accepted orders without a dependable view of kitchen capacity, menu availability, or delivery-zone load. Customers repeated checkout steps after payment delays and contacted support because order status changed inconsistently. Administrators moved between restaurant messages, payment exports, and driver updates to understand a late order.

The new platform needed one canonical order state, server-controlled totals, fast consumer pages, and an admin queue that prioritized exceptions rather than forcing operators to inspect every healthy order.

Solution and order workflow

Next.js delivered location-aware restaurant and menu pages with server-rendered metadata. TailwindCSS components handled item options, allergens, availability, cart totals, delivery estimates, and responsive checkout. MongoDB stored restaurants, menus, modifiers, orders, service zones, and immutable price snapshots. Redis cached frequently viewed menus and maintained temporary capacity and reservation counters.

The order state machine defined valid transitions from payment pending through accepted, preparing, ready, dispatched, delivered, cancelled, or refunded. Delayed events could not move an order backward:

if (!allowedTransitions[order.status].includes(nextStatus)) {
  throw new Error("Invalid order transition");
}
await updateOrder(order.id, nextStatus);

WebSocket events updated the consumer timeline and admin queue after a committed state change. Push and email notifications were produced through an outbox worker so a temporary provider outage never blocked the order API.

Consumer and admin capabilities

• Address-based restaurant discovery, search, dietary filters, and delivery estimates.
• Modifier-aware menus, cart validation, coupons, taxes, fees, and secure payment.
• Live order timeline with useful explanations for delay or reassignment.
• Admin menu availability, kitchen queue, delivery zones, and capacity controls.
• Exception views for payment failure, rejected order, delay, address, and refund.
• Revenue, preparation time, delivery performance, ratings, and item analytics.

Key engineering decisions

The browser never supplied a trusted order total. The server reloaded menu prices, validated modifiers, checked delivery coverage, and calculated fees before creating a payment request. The order stored that confirmed snapshot so later menu edits did not change a receipt.

Real-time messages were treated as a delivery channel, not the database. Clients reconnecting after a network loss requested the canonical order plus events after their last sequence. Admin dashboards showed a freshness indicator and degraded gracefully to polling. Exact driver coordinates were restricted to active operational need, retained briefly, and never exposed as general employee monitoring.

Delivery and validation

Contract tests verified menu, payment, notification, and delivery event schemas. Scenario tests covered closed restaurants, unavailable modifiers, coupon conflicts, capacity limits, duplicate webhooks, reassigned deliveries, cancellation windows, and partial refunds. Multi-page browser tests confirmed that consumer and admin views converged on the same order after every accepted change.

The rollout began with selected delivery zones and a limited restaurant group. Dashboards tracked checkout failure, restaurant acceptance time, kitchen age, dispatch delay, WebSocket replay depth, and notification success. Synthetic orders ran continuously without entering real fulfillment. Accessibility review covered menu customization, cart totals, status announcements, keyboard navigation, and error recovery. Support and operations teams received exception-specific runbooks before broader activation.

Outcomes

The simplified cart and server-confirmed checkout improved completion speed by 29%. A consistent timeline and proactive delay messages reduced order-status support contacts by 33%. Zone capacity controls and prioritized exception queues improved on-time delivery by 18% during the measured period.

Administrators could resolve failed payments, kitchen delays, and address issues from one record. Customers received more accurate promises, while structured status history made restaurant and delivery performance measurable without reconstructing events from messages.

Related work

The payment and inventory safeguards relate to the ecommerce consumer, seller, and admin platform. Real-time synchronization patterns are explored in the collaborative planning platform and modern full-stack development guide.