Food delivery marketplace

In development.

Food delivery is a three-sided problem. Customers order, restaurants fulfil, drivers deliver, and money has to move correctly between all of them. Most builds stop at the menu and the cart; this one models the settlement and logistics underneath.

Type: In-house product
Scope: Full stack, Django backend, Next.js customer app

Built with

Django
PostgreSQL
Next.js
Google Maps
Zustand

What we built

Customer web app with address entry, phone number handling, and Google Maps for delivery addresses
Ordering domain covering orders, line items, per-item modifiers, promo codes, and redemption tracking so a discount cannot be reused
Driver side with driver records, live location, delivery assignment, and payout accounting
Customer wallets backed by a transaction ledger, alongside subscription support
Notifications, reviews, and daily restaurant and platform metrics for reporting

Decisions worth explaining

Modelling the money, not just the menu

Wallets are backed by a transaction ledger, promo codes track redemption per user so a discount cannot be quietly reused, and driver payouts are accounted separately from order revenue. Most food delivery builds stop at the cart. The genuinely hard part is that a single order moves money between a customer, a restaurant and a driver, and every one of those legs has to reconcile.

Delivery is its own lifecycle

Drivers, live location, assignment and payouts are modelled independently of orders, because a delivery has states an order does not. Collapsing the two is the shortcut that makes dispatch and driver payment painful to build later.

Reporting designed in, not bolted on

Daily restaurant and platform metrics are first-class tables written as events happen, rather than reports invented afterwards by scanning the orders table. Analytics added late tends to mean expensive queries over data that was never shaped to answer them.

Yours could be next.

Start a project

Next project

Real estate and construction