Skip to content
Rathaworks

Case study · Private restaurant clientFive apps that let one restaurant run its own delivery

Customer app and website, rider app, kitchen portal and owner panel on one live backend — so a single restaurant can run delivery without paying an aggregator.

Built at GravitonesDelivered

The restaurant asked not to be named, so its name and branding are left out.

Industry
Food & restaurants
Location
India
Timeline
2 months
Year
2026
Illustration of a restaurant delivery platform: customer live tracking, rider pickup code and kitchen order board
Illustration of the product. The client's production interface is confidential, so it isn't shown here — I can walk you through it on a call.

Results

connected apps on one live backend
0
connected apps on one live backend
screens across customer, rider, kitchen and owner apps
0+
screens across customer, rider, kitchen and owner apps
API endpoints, with real-time updates over Socket.IO
0+
API endpoints, with real-time updates over Socket.IO
user roles — from chef to finance manager
0
user roles — from chef to finance manager

The challenge

What the client needed.

The restaurant had a working kitchen and no software: orders arrived by phone and messaging apps, a paper list sat on the counter and cash was reconciled from memory at night. They wanted to stop paying aggregator commissions and run delivery themselves — which means everything an aggregator provides has to exist and work on day one, for a business too small to absorb mistakes.

My role

Lead developer — API, customer app and website, rider app, restaurant portal and owner panel

The approach

How I built it.

  1. 01

    Built five apps on one Express + PostgreSQL backend: a customer app and website, a rider app, a restaurant and kitchen portal and an owner control panel.

  2. 02

    Priced delivery on real road distance from Google's Routes API, cached per address, with a straight-line fallback that can only ever be generous if the mapping service is down.

  3. 03

    Made the operation live with Socket.IO: new orders chime on the kitchen board, riders get assignments instantly and customers watch the rider on a map — every connection scoped to the verified user.

  4. 04

    Added physical verification: a short bag number checked at pickup (hidden from the rider until confirmed) and a delivery code sent to the customer.

  5. 05

    Recorded every cash collection as its own entry and built settlements that close exactly the collections they cover.

  6. 06

    Gave seven roles their own workspace and put pricing, delivery radius, tax and an open/closed switch in the owner's hands.

Key engineering decisions

The hard problems, and how I solved them.

The decisions that made the difference — each one a trade-off chosen on purpose.

  1. 01

    What a delivery actually costs

    Problem
    Straight-line distance undercharges the longest trips and accepts addresses the kitchen can't realistically reach.
    Decision
    Fees and the delivery boundary use real road distance, cached per address, and fail generously if the map API is down.
    Outcome
    Fees track real cost, and out-of-range customers learn it before they build a basket.
  2. 02

    The right bag at the right door

    Problem
    Identical sealed bags on a busy counter get swapped — one mistake ruins two orders.
    Decision
    Four-digit bag numbers verified at pickup and never shown to the rider beforehand, plus a customer delivery code.
    Outcome
    Mix-ups are caught at the counter, and every handover has a confirmed moment.
  3. 03

    Following the cash

    Problem
    Cash in riders' pockets was reconciled from memory at the end of the night.
    Decision
    Each cash collection is an individual event; a settlement subtracts exactly the collections it covers.
    Outcome
    Reconciliation became a receipt both sides can check, not a negotiation.
  4. 04

    Five apps, one truth

    Problem
    Five front ends drift apart as features land, and breakages surface in front of customers.
    Decision
    One OpenAPI contract with generated clients, shared pricing rules, and map keys kept on the server.
    Outcome
    A change that would break another app is caught at build time.

What shipped

Everything that was delivered.

  • Customer app

    iOS & Android: menu, variants and add-ons, cart, coupons, online or cash payment, live rider tracking, ratings.

  • Customer website

    The same ordering experience for desktop and first-time visitors.

  • Rider app

    Assignments, navigation, bag-number pickup, delivery codes, earnings and cash position.

  • Restaurant portal

    Live order board with alerts, kitchen queue, menu and stock, staff and analytics.

  • Owner control panel

    Pricing, delivery radius, banners, coupons, broadcasts, finance, settlements and support.

  • Real-time API

    Express, PostgreSQL and Socket.IO with server-proxied Google Maps and Razorpay.

Tech stack

  • React Native
  • Expo
  • React
  • Vite
  • Node.js
  • Express
  • PostgreSQL
  • Drizzle ORM
  • Socket.IO
  • Razorpay
  • Google Maps Routes API
  • AWS S3
  • OpenAPI

Services used on this project

Get results like this

Next case study

QuickBite

A creator-led food discovery app where reels turn into verified visits

Read it

Want results like these for your business?

Tell me what you need in two minutes. You'll hear back within 24 hours, and get a fixed-price proposal within 48 hours of our call.

Get your free project quote
Chat on WhatsApp
  • Reply within 24 hours
  • Fixed quote in 48 hours
  • NDA on request