Case Study
Live in production · Ordering, loyalty, kitchen & dispatch

Harry & Sherry Stopped Renting Their Menu Back From Foodpanda.

Harry & Sherry is a real dessert shop in Sargodha - three branches, five years running, 4.9★ on Foodpanda. Every one of those five-star orders was still handing a slice of margin to a delivery app and zero customer data back to the shop. We built them the system that fixes that: ordering, loyalty, kitchen, and dispatch, all running off one database, all owned by them.

3
Branches served
90
Menu items live
4.9★
Foodpanda rating
4
Dashboards, one order
The Problem

A 4.9★ Shop Doesn't Need a Better Menu. It Needs to Own the One It Has.

Harry & Sherry didn't have a discovery problem - customers already loved them enough to leave a near-perfect rating. What they had was a commission problem: every order that came in through a delivery app took a cut before it ever reached the shop, and every one of those customers belonged to the app's database, not theirs.

No loyalty program that meant anything. No direct line to a repeat customer. No way to see, in real time, what was moving through three branches at once. Five years of goodwill, sitting on someone else's platform.

What We Built

Not a Menu Site. An Operating System for the Shop.

Four surfaces, one database. A customer places an order, and it's live in the kitchen, the rider's queue, and the owner's dashboard within the same second - no refreshing, no separate systems to reconcile.

01

Customer Ordering

The full 90-item menu, cart, and checkout - built around how Harry & Sherry actually sells, not a generic storefront template.

02

Loyalty & Rewards

A points program modeled on McDonald's/KFC-style redemption - points buy real menu items, not a discount code. The kind of loyalty program that actually gets a customer to order direct next time.

03

Live Order Tracking

Customers see their order move in real time - placed, accepted, in the kitchen, out for delivery - without needing to ask.

04

Kitchen Queue Dashboard

Oldest-first, and a ticket visibly ages the longer it sits - so nothing gets forgotten during a rush.

05

Rider Dispatch Dashboard

A rider claims a delivery and it locks to them - so two riders never show up for the same order.

06

Owner Dashboard

Live sales, staff roles, menu editing, and the rewards catalog itself - all editable with no code, by the owner, whenever they want.

Accept an order in the kitchen and it appears in the rider's queue within the same second. All four surfaces run off one order, in real time - not four systems someone has to keep in sync by hand.

Watch Every Screen, Back to Back

A full walkthrough of the ordering flow, the loyalty catalog, live tracking, and all three dashboards - the same system shown above, actually running.

The Engineering, Not Just the Interface

This Is the Difference Between a Website and a System

Anyone can ship a menu page. What actually protects a restaurant's revenue is what's underneath it - so here's what's underneath this one.

PROOF 01 - SECURITY

Nothing the client says about price is trusted

Every reward and every price is re-resolved server-side, inside the order transaction itself - not read from whatever the app sent. A single combined-balance check covers both cash-redeemed points and item-redeemed rewards in the same order, closing an overdraft path that two separate checks would have missed.

Verified with direct database role-impersonation testing - guest, wrong-owner, insufficient balance - before a single screen of UI existed.

PROOF 02 - REAL-TIME ARCHITECTURE

No dashboard is ever polling for an update

Built on Supabase Realtime Broadcast instead of a refresh timer, so an order's status change reaches every dashboard that needs it - kitchen, rider, owner - instantly, the moment it happens.

PROOF 03 - A DEBUGGING STORY

Found the real cause instead of shipping a patch

Passwordless login worked in every manual test, then failed silently for real users. Root-caused to Gmail's own security scanner prefetching the single-use magic link before the customer ever clicked it - a documented Supabase limitation, not a bug in our code.

A 6-digit-code fix was built and tested, then shelved cleanly on hitting a real infrastructure wall - it needs custom email hosting, which needs a domain - rather than shipping something half-working.

PROOF 04 - A PERFORMANCE STORY

Measured the slowdown instead of guessing at it

The live site felt sluggish. Instead of guessing at a fix, we measured actual load time, found the hosting function region (US East) didn't match the database region (Mumbai), and fixed it by pinning the region. Load time dropped immediately - confirmed with before/after measurement, not a hunch.

The Stack

Built to Last, Not Built to Demo

Production tools chosen for reliability at restaurant scale, not the fastest thing to prototype in.

Next.js 16
TypeScript
Tailwind CSS v4
Supabase (Postgres)
Row-Level Security
Supabase Realtime
Vercel
See It Yourself

This Is What "Your Own System" Actually Looks Like

Harry & Sherry is live in production end to end - ordering, loyalty, kitchen, dispatch, owner dashboard - running for a real shop with three branches. Want the same thing built around your menu?

Get Your Custom Quote on WhatsApp