Home Work Tamba Restro

3 of 5 public 2 inside the shop only

One restaurant, five ways to order.

Tamba Restro in Badarpur takes orders in five different ways. Before this, each way was a separate system, and none of them agreed with the others. Now it is one system. All five read the same menu and the same stock count, so the kitchen never gets an order it cannot cook.

next.js 14turborepo supabasecloudflare pages & workers razorpaymsg91borzo

tamba-website.kesar-restroo.workers.dev/menu open

loading tamba restro…

click to scroll inside

apps

commits

637

screens built

440

data updates

status

Live and in use

the problem

Five systems that never agreed with each other

A restaurant that sells online ends up with a pile of software nobody planned together. The website is from one company, the Zomato tablet from another, the billing from a third. The only thing joining them is a staff member retyping orders during the dinner rush.

The typing is not the real problem. The real problem is that nothing agrees. An item sells out at the counter and keeps selling online for another forty minutes. A price changes in one place and not in the other four. Someone orders a dish the kitchen stopped making in March.

So we did not build five apps. We built one system with five ways in. The menu, the prices, the stock count and whether you are open are stored once. All five read from that one place.

Change a price once. All five know it before the next order arrives.

menu, shared by all five

orders retyped by hand

the five ways in

All five, and what each one is for.

Three of these you can open right now. Two only run on machines inside the shop, so there is no link we can give you. We show you the real screen instead.

tamba-website.kesar-restroo.workers.dev/menu open

loading…

click to scroll inside

01 desktop web · next.js on a cloudflare worker

The ordering website

The customer-facing storefront. This is the live menu, so the categories, prices and availability you see are whatever the restaurant has switched on this minute.

21 live categories with meal-deal bundles and strike-through pricing
The cart switches between delivery, takeaway and dine-in, each with its own rules
Address-aware delivery, a rewards tier, and banquet booking for up to 500 guests

Open the site

tamba-pwa.pages.dev/menu open

loading…

click to scroll inside

02 phone app you can install

The customer's phone app

Customers add it to their phone straight from your website. No app store needed. The same menu as everywhere else, laid out for a thumb.

The menu is saved on the phone, so it opens even on weak signal
Order tracking, rewards tier and saved addresses, with a simple OTP login
The same app can be turned into a Play Store download when the client wants one

Open the app

tamba-kiosk.pages.dev open

loading…

click to scroll inside

03 portrait touchscreen · floor-standing

The self-order kiosk

A screen that stands near the door and takes the overflow off the counter. Portrait, no keyboard, targets big enough to hit with a thumb while holding a bag.

Orders drop into the same kitchen queue as the till and the website
Runs as a locked-down browser session that recovers on its own after a power cut
Sold-out items disappear the moment stock hits zero, so nobody queues for something that is gone

Open the kiosk

tamba-dinein.pages.dev · paired to a table open

Screenshot pending Send the real tablet capture and it appears here:
assets/screens/tamba-dinein.png

loading the dine-in build…

04 tablet on the table · in-venue

The dine-in tablet

Fixed to the table and linked to that table number. Guests order the moment they decide, instead of waiting for a waiter, and it reaches the right table in your billing.

Each tablet is bound to a table number, so the order reaches the right seat in the POS
Table games award a discount, but the score is checked on the server and applied at billing — never trusted from the tablet
Call-a-server and request-the-bill go straight to the till

unpaired without a table token

tamba-delivery.pages.dev · staff sign-in open

Screenshot pending Send a capture from a signed-in rider phone:
assets/screens/tamba-rider.png

loading the rider app…

05 staff phone app · sign-in required

The rider app

What the delivery staff carry. A job board rather than a consumer app: accept, navigate, mark delivered. It sits behind a staff login because it shows live customer addresses.

When your own riders are all busy, an outside delivery service takes over automatically
Every update shows on the customer's tracking screen straight away
Built to survive a dying phone battery and a patchy signal on the road

staff credentials required

how it holds together

One system, five apps

All five apps live in one project. The menu, the prices, the tax rules and the look are written once and shared. A rule written in one place is the same rule in all five apps.

Supabase holds the shared data with twenty tracked data updates mean the database can be rebuilt exactly rather than something that accumulated. Payments go through Razorpay, phone verification through MSG91, and dispatch through Borzo when the in-house riders are saturated.

Hosting is Cloudflare — Pages for the static surfaces, a Worker for the website. Deploys are per-app, so shipping a kiosk fix does not redeploy the storefront in the middle of dinner service.

front ends

next.js 14reacttypescriptcapacitor

data

supabasepostgresrow-level security20 migrations

hosting

cloudflare pagescloudflare workers

integrations

razorpaymsg91 otpborzo dispatch

tooling

turboreposhared design tokens

next project

GOD POS

The till underneath all of this — a billing system that runs the whole restaurant from one machine inside the shop, with no internet needed.

We can do this for yours.

If your surfaces disagree with each other, that is the exact shape of problem this studio is built for.

Start a project orca.devss@gmail.com