Menu that the owner controls
Items, prices, photos, and per-outlet availability. Marking something sold out takes one tap and applies to that outlet only.
CASE STUDY
Example buildMobile AppRestaurant Ordering App
Menu, cart, live order tracking and a simple kitchen dashboard for a multi-outlet restaurant.
- Type
- Mobile app + web dashboards
- Build time
- 12–16 weeks
- Platforms
- iOS, Android, tablet
- Starts at
- ₹1,20,000*
This is an example build. Tavzuran is a new studio with no client work to show yet. This page describes how the project would be scoped and built — the same thinking you would get on a real one. Nothing here is a past client, and no number on this page is a result.
The price follows the feature list. The number above buys everything scoped on this page. Take features out and it comes down — the shortest route to a smaller number is a shorter list, and deciding what to drop is what the free call is for.
THE SITUATION
What's actually broken.
A restaurant with three outlets takes orders over the phone and on a delivery aggregator that keeps 25–30% of every bill. The owner wants their own ordering channel for regulars, so repeat customers stop costing commission on every order.
The hard part is never the menu screen. It is what happens after someone taps Pay: which kitchen sees the order, what the customer sees while they wait, and what happens when an item is out of stock at one outlet but not the others.
Every repeat order pays 25–30% commission to an aggregator
Phone orders get written down wrong at peak time
No idea which outlet is behind until a customer complains
Sold-out items are only discovered after someone has paid
VERSION ONE
What we'd build first.
Every item here earns its place by being something a real user would miss on day one.
Cart and checkout
Address, delivery or pickup, and a payment gateway. No account required to order — a phone number and an OTP is the whole signup.
Live order tracking
Accepted → cooking → out for delivery → delivered, pushed to the customer's phone as it changes. This is the screen that decides whether people order again.
Kitchen dashboard
A tablet screen per outlet showing incoming orders large enough to read across a kitchen, with one button to advance an order's state.
Owner view
Today's orders, today's revenue, and which items are actually selling. Three numbers, not a business-intelligence suite.
DELIBERATELY NOT IN V1
What we'd leave out.
Not because these are bad ideas. Because each one is designed better once the first version has told you something.
- Loyalty points and coupon engines — worth building once there is repeat-order data to design them around.
- In-house delivery-rider tracking. Most restaurants at this size use a third-party rider fleet at first.
- Table reservations and dine-in QR ordering. A separate problem with a separate set of screens.
UNDER THE HOOD
How it's put together.
- Customer app
- React Native, so iOS and Android ship from one codebase
- Kitchen and owner screens
- A responsive web app — a tablet browser is cheaper and easier to replace than a native install
- Backend
- Node with a Postgres database
- Realtime
- WebSockets for order state, so the kitchen screen updates without anyone refreshing anything
- Payments
- A standard Indian gateway (Razorpay or equivalent)
HOW IT RUNS
Week by week.
-
01
Week 1
Menu structure, outlet model and the order state machine agreed on a call. This is the part that is expensive to get wrong.
-
02
Weeks 2–8
Customer app and checkout.
-
03
Weeks 9–13
Kitchen dashboard, live tracking, owner view.
-
04
Weeks 14–16
One outlet runs it live for a week or two before the others switch on.
THE HARD PART
Keeping three kitchens and one customer in agreement
Every build has one problem that decides whether the rest of it matters. This is that problem, written out.
The screens are the easy half. The difficulty is that an order is a shared piece of state being changed by four parties — the customer, the kitchen, the rider and the payment gateway — none of whom are looking at the same screen and any of whom can act at a moment the others do not expect.
The specific failure to design against: a customer pays, and the kitchen then discovers the item is finished. Money has moved and the product cannot be delivered. That path needs a decided answer — automatic refund, substitution offer, or a call — before a line of code exists, because retrofitting it means touching payments, notifications and the kitchen screen at once.
The other one is stock. Marking an item sold out has to reach every device holding a menu within seconds, or two more customers order it while the kitchen is still typing. That is why order state runs over a live connection rather than being polled every thirty seconds.
BEFORE A PRICE EXISTS
What we'd ask you first.
A quote given without these answers is a guess. These are the questions that actually move the number.
- 01How many outlets, and do prices or menus differ between them?
- 02Who answers the phone at 8pm on a Friday, and what breaks first?
- 03Do you deliver with your own riders or a third-party fleet?
- 04Roughly what share of orders are repeat customers today?
- 05Is there a POS the kitchen already uses that this has to sit beside?
AFTERWARDS
How we'd know it worked.
Agreed before the build starts, so there is something to judge it against other than whether it looks nice.
- A third of repeat orders move off the aggregator within three months — that is the commission this is meant to save.
- Kitchens accept new orders within ninety seconds during peak hours.
- Under two per cent of paid orders are cancelled after payment.
- The owner opens the daily summary without being reminded to.
BEFORE YOU START
Worth knowing.
The app-store fees, the payment gateway's per-transaction cut and the cloud hosting are billed to you directly by those providers. They are not part of the build price.
Websites and apps start at ₹20,000*. Final pricing depends on features and project scope. Third-party costs — cloud hosting, domains, external libraries, APIs, app-store fees and any other paid service — are billed separately and are not included.
KEEP LOOKING
Other example builds.
Web App
Coaching Management Platform
Batches, attendance, online tests and fee payments in one dashboard for students and staff.
Read the case study Web AppBusiness Automation Dashboard
Replaces daily spreadsheet work with automated reports, alerts and role-based access.
Read the case study Website + CRMReal Estate Listing Portal
Property search, enquiry capture and a lead pipeline a sales team will actually use.
Read the case studyWant this built for your business?
Tell us what you're thinking. We'll figure out the next step together.
Free 20-min idea call · No obligation