What does restaurant POS software actually do during a service?
Restaurant POS software is the system that turns an order into a kitchen ticket, a bill and a stock movement, and keeps all three consistent. That one sentence hides a lot of moving parts, and a Friday dinner rush is where weak software shows.
Walk through a single table. A captain takes the order on a phone, the POS splits it by station and sends the dal makhani to the main kitchen and the mocktails to the bar, each as a KOT. The kitchen marks items ready. The guest adds a dessert, which fires a second KOT without reprinting the first. At the end, the bill shows the right GST breakup, the guest pays by UPI, and the recipe for every dish sold quietly reduces butter, paneer and cream in your stock ledger. At night, the manager closes the day and the owner sees sales, voids and discounts on their phone.
A retail billing app can print a bill. It usually cannot do the KOT split, course firing, table transfers or recipe deduction, which is why restaurants need POS software designed for food service.
When should a restaurant get its own POS instead of a ready-made one?
Get your own restaurant POS software when the subscription product has become a constraint, not just a cost. For a single café with a standard menu, a ready-made POS is the sensible choice, and we will tell you so on the first call.
The signals that a custom build is worth pricing are practical ones. Look for staff keeping a parallel Excel sheet because the POS cannot handle a combo rule, a manager exporting data every night to build the one report the owner actually reads, or a franchise model where royalty and central kitchen billing are still worked out by hand.
- Per-outlet fees and add-on charges are growing faster than your outlets
- Your service flow (live counters, thali refills, buffet plus à la carte, banquets) needs workarounds
- You run a central kitchen that transfers semi-finished items to outlets
- You want your sales and customer data in your own database, queryable any time
- You plan a franchise and need royalty, outlet audits and menu control in one place
- You want the POS linked to your own app, website ordering or loyalty programme
If only one or two of these apply, try asking your current vendor first. If four or more apply, a custom build usually pays back; our custom software cost guide shows how that maths works.
KOT printing or a kitchen display screen: which should your POS use?
Use printed KOTs if your kitchen is small and your cooks are used to paper; move to a kitchen display system (KDS) when you have several stations, many delivery orders, or you want preparation times measured. Good restaurant POS software supports both, per station.
A KOT printer is cheap, familiar and works with a bad network, because the POS can print over the local LAN. The weakness is that nothing flows back: the counter does not know the paneer tikka is ready, and nobody knows how long it took.
A kitchen display on an Android tablet or a wall screen shows each ticket with a running timer, turns amber and then red when late, and lets the cook bump items to “ready”. That data answers real questions: which dish slows the pass, which hour needs an extra cook. The cost is hardware per station and a little training.
Station routing
Every menu item is tagged to one or more stations. A mixed order is split automatically, and a “fire together” flag keeps a table’s mains arriving at the same time.
Modifiers and notes
Jain, no onion, extra spicy, half portion: modifiers print in bold on the KOT or show in a colour on the KDS so they are not missed.
Cancellations
A cancelled item prints a clear void KOT to the station and needs a reason and a manager PIN, which closes a common leakage route.
The captain ordering app: what it needs to get right
A captain app is a small Android app used by floor staff to take orders at the table and send them straight to the kitchen. It sounds simple, and it is where most restaurant POS software projects win or lose staff trust.
Captains work fast, with one hand, in dim light, often on inexpensive phones. So the app needs large tap targets, a search that understands short codes (“PBM” for paneer butter masala), favourites per section, and an order summary that is readable at arm’s length. It must keep working when the Wi-Fi flickers: orders queue on the device and sync the moment the connection returns, with a clear indicator so nobody sends an order twice.
We build captain apps in Flutter, which gives one codebase for Android and, if you ever want it, iOS. Distribution can be private, through a managed Google Play track or a direct APK install on restaurant-owned phones, so the app does not need to be public. Staff log in with a PIN, and each order carries the captain’s name for accountability and tip reports.
For a broader look at app builds of this kind, our freelance app developer page covers Play Console setup and ownership.
Can custom restaurant POS software take Swiggy and Zomato orders?
Yes, provided your restaurant has integration access from the platforms or works through an integration partner they approve; the developer cannot switch this on alone. This is the question to settle before anything else, because it decides how delivery orders reach your kitchen.
Aggregators share order data with POS systems through partner integrations. Access is granted by the platform, under its own terms, and those terms can change. In practice there are three routes. You may already qualify for direct API access and receive credentials; we then connect your POS to it. You may use an existing integration middleware service that the platforms already work with, and we connect your POS to that service’s API. Or, if neither is available yet, orders are accepted on the aggregator tablet and a staff member pushes them into the POS with a quick-entry screen, which still gets them into one KOT queue and one sales report.
Whatever the route, the POS design is the same: every channel (dine-in, takeaway, aggregator, your own website) becomes an order source, with its own commission and packaging charges, so your channel-wise profit report is honest. If you plan your own ordering channel, our WhatsApp ordering system page shows how direct orders can feed the same queue.
GST billing, UPI and day-close in restaurant POS software
Your POS should print bills that your CA is happy with and close the day without a calculator. That means GSTIN on the bill, the correct tax lines for the rate your CA confirms applies to your restaurant, HSN or SAC codes where needed, and a numbering series per outlet that never skips.
We do not decide tax rates; rates and exemptions for restaurant services are set by GST notifications and depend on your setup, so your CA confirms the configuration and we build it that way. The software then applies it consistently, including on complimentary items, staff meals and discounts.
Payments are where leakage hides. A good build records the payment mode on every bill, supports split payments (part UPI, part cash), shows a dynamic UPI QR with the exact bill amount on a customer-facing screen or on the printed bill, and marks the bill paid only after confirmation from your payment provider. At day close, cash in drawer, UPI settlements and card batches are compared against the system, and the difference is shown in rupees, not hidden.
- Bill series per outlet, with void and reprint logs
- Discount and complimentary reasons, approved by PIN
- Payment mode split and settlement matching
- Shift handover and cash-drawer count
- Day-end report on the owner’s phone and WhatsApp
Recipe-level stock: how restaurant POS software finds your food cost
Recipe-level stock means every dish is broken into ingredients with quantities, so each sale automatically deducts what it should have used. The gap between that theoretical usage and your physical count is your real wastage and pilferage figure.
Setting this up is more kitchen work than software work. Someone has to write down that a plate of chicken biryani uses so many grams of rice, chicken, oil, onion and masala, including yield loss when chicken is cleaned. We give you a spreadsheet template, your chef fills it, and we import it. Semi-finished items such as gravies, doughs and marinades get their own recipes, so a batch of makhani gravy can be produced once and consumed by six dishes.
Once running, the POS shows food cost per dish, per category and per day, flags items whose margin has dropped after a price rise from a supplier, and suggests purchase quantities from par levels. Purchase entries, goods received and supplier bills sit in the same module, and a weekly physical count closes the loop. If you already track stock elsewhere, see our inventory software page for how the two can be linked.
Multi-outlet and central kitchen control in one POS
Multi-outlet restaurant POS software lets you change a menu or price once and push it to every outlet, while each outlet keeps billing even if the head office link is down. This is where custom builds most often beat subscriptions, because every chain runs its own way.
The design choice we care about is simple: each outlet has a local database that keeps working offline, and a central cloud database collects everything when the connection is up. Menus, prices and taxes flow down; bills, KOTs, stock and cash flow up. Owners see live outlet-wise sales, top items, voids and average bill value on a phone dashboard.
A central kitchen adds another layer. Outlets raise indents, the central kitchen dispatches semi-finished items with a transfer note, and each outlet’s stock and food cost reflect the internal transfer price. For franchises, the same data feeds royalty calculation and outlet audits; our franchise management software page covers that side in more depth.
Permissions get more careful as outlets multiply. An outlet manager can change today’s specials and mark items out of stock, but only head office can change base prices or tax settings. Area managers see their cluster, the owner sees everything, and every price change carries a name and a timestamp.
Will restaurant POS software keep billing when the internet goes down?
It must. A POS that stops billing when the broadband fails is a liability during a full house, so we build local-first: the counter, KOT printers and captain phones talk over the restaurant’s local network, and the cloud is for syncing, reports and backups.
Technically, the billing terminal runs a local database. Orders, bills and payments are written there first, each with a unique ID generated on the device, so nothing clashes when the data syncs. When the connection returns, a sync service uploads the queue in order and downloads any menu or price changes. The screen shows a small status light so the manager knows whether the outlet is synced.
There are honest limits. UPI confirmation needs the internet on at least the customer’s phone or the payment terminal, and aggregator orders need connectivity too. For those minutes, the POS records the payment as pending and asks the cashier to verify later. We also recommend a cheap 4G backup router, which is a hardware decision you make; we only configure the POS to use whatever network is available.
Hardware for restaurant POS software: what you buy and what we set up
You buy standard hardware from any local supplier; we specify it and configure the software to work with it. We do not sell, install or repair hardware, and we cannot visit your outlet, so a staff member or your hardware vendor does the physical setup while we guide on a video call.
A typical outlet needs one billing terminal (a touchscreen PC, a laptop or an Android tablet), one thermal printer per kitchen station, a bill printer, a cash drawer, a router, and two or three Android phones for captains. Kitchen display stations use wall-mounted Android tablets or a TV with a small Android box. We choose widely available thermal printers that accept standard ESC/POS commands, because they are easy to replace from any supplier.
- Billing terminal: touchscreen PC, laptop or 10-inch Android tablet
- Thermal printers: 80 mm for bills, 80 mm or 58 mm for KOTs
- Captain phones: mid-range Android with a sturdy cover
- KDS: Android tablet or TV per busy station
- Network: wired router for printers, Wi-Fi for phones, 4G backup
Before buying anything, send us the models you are considering on WhatsApp. A two-minute check can save you from a printer that needs a proprietary driver or a tablet too weak to run a kitchen display for a twelve-hour shift.
The technology behind a custom restaurant POS
We keep the stack boring and well supported, because a POS has to run for years without surprises. The back office is a web app (TypeScript on Node.js or Python, PostgreSQL), the billing terminal is either a desktop app or an installable web app with an offline database, and the captain and KDS apps are Flutter.
Why these choices? PostgreSQL handles reporting queries across months of bills without fuss. A web-based back office means owners and accountants can log in from anywhere. Flutter lets one developer maintain the captain app, KDS and a customer app from shared code. Hosting goes on a mainstream cloud provider in an Indian region, in your account, with daily backups you can download.
Another of us handles the cloud, database and reporting side, one of us builds the POS screens and apps, and the third of us runs the plan, testing and staff training sessions. Three people is a real limit: we will not pretend to be a 20-person product team. It is also why every one of us knows your code. For the back-office side in more depth, see web application development.
How long does it take to build restaurant POS software?
A first working release of custom restaurant POS software takes 6–12 weeks, depending on how many modules go into it. We never try to launch everything at once in a live restaurant; we release in stages so staff learn one change at a time.
A common plan: weeks one and two for menu import, table map, order-to-KOT and bill design; weeks three to five for payments, day close, captain app and reports; then a pilot in one outlet during quiet hours, running parallel to the old system for a few days. Stock, aggregator intake and multi-outlet features follow in the next release once the core is stable.
What slows projects down is predictable: an unclean menu sheet with duplicate item names, recipes not written, hardware arriving late, and decisions about discounts and permissions that nobody wants to make. A single owner-side decision maker speeds everything up.
During the build you see progress every week on a staging POS you can open on your own phone. Place fake orders, print sample KOTs on a spare printer, and send comments as WhatsApp voice notes if that is easier than typing. Each week ends with a short list of what changed and what is next, so there are no surprises on pilot day.
Who owns the POS code, the data and the customer list?
You do. The source code sits in a repository you own, the cloud account and database are in your business name, and the domain for the back office is registered to you. Guest phone numbers and order history are your customer list, not a vendor’s.
That matters more in restaurants than people expect. Your order history is the base for loyalty offers, menu engineering and forecasting. When it lives in your own PostgreSQL database, you can query it, move it to another developer, or connect it to a loyalty app later without asking anyone’s permission.
At handover you receive repository access, admin logins, a hardware and printer settings sheet, a short staff manual in English and Hindi, and a list of every paid cloud service with its renewal date. The first two months of maintenance are free; after that care is optional, from ₹8,000/mo. If you would rather have another team maintain it, the code and documentation let them take over.
One more point on data: guests should know why you collect their number. We can add a short line on the bill or feedback page explaining that the number is used for e-bills and for offers the guest agrees to, plus an opt-out. What that notice must say under India’s data protection law and WhatsApp’s messaging policy is for your own lawyer to confirm; the software simply records each guest’s consent.
Risks and red flags when commissioning restaurant POS software
The biggest risk is not bad code; it is going live on a busy night without a pilot. Plan the switch-over for a quiet weekday, keep the old system available for a week, and train captains before cooks.
- A developer who has never asked how your kitchen stations are laid out
- No offline plan, or “the internet is always on” as the answer
- Promises of aggregator integration without mentioning platform approval
- Source code or cloud account held in the developer’s name
- No void, discount and reprint logs, which are how leakage is caught
- One lump-sum quote with no module-wise breakdown
- No stated plan for updates after launch
Also watch for scope creep on your own side. Loyalty, table reservations and a customer app are good ideas; they belong in release two. A focused first release gets staff on board faster.
Finally, ask any developer how they test. For restaurant POS software, testing means a full mock service: several captains ordering at once, a printer unplugged mid-order, the router switched off, a split bill with UPI and cash, and a day close at the end. If they only test screens one by one, the rush will find the bugs for them.
Worked example: a three-outlet biryani brand moving off a subscription POS
This is a hypothetical scenario to show how a project would run, not a client story.
Say a biryani brand runs two dine-in outlets and a delivery-only kitchen, with a central kitchen that cooks the rice and gravies. They pay per-outlet fees, their royalty and transfer pricing live in Excel, and the owner wants one dashboard. The brief: order-to-KOT with three stations, captain app for the two dine-in outlets, GST bills with UPI, central kitchen indents and transfers, recipe stock for the top forty items, and aggregator orders in the same queue.
We would quote the custom software plan from ₹60,000, with separate lines for the captain app, the central kitchen module and the aggregator intake route they qualify for. Release one, in about six weeks, covers billing, KOT, captain app and day close in the delivery kitchen first, because it has no tables and is the easiest pilot. Release two adds the dine-in outlets, central kitchen transfers and recipe stock. The owner’s dashboard ships with release two. Their old system stays live in read-only mode until the first month closes cleanly.
Restaurant POS software for outlets across India
We build remotely for restaurants in any city; setup happens over video calls with your staff or hardware vendor on site. Menu habits change by region, and the software follows them: thali refills in Gujarat, live dosa counters in the south, tandoor-heavy kitchens in Punjab, momo stations in the Northeast.
Owners in Hyderabad, Bengaluru, Kolkata, Lucknow, Amritsar, Indore, Kochi, Ahmedabad, Pune and Guwahati can read about local business context on their city pages. Bills can carry item names in Hindi or a regional language alongside English where your guests prefer it.
Running a hotel with a restaurant attached? The POS can post room-service and restaurant charges to a guest folio; our hotel management software page explains that link.
Payments follow the Indian norm: UPI or bank transfer, in stages tied to releases you have seen working. International restaurant groups can pay in USD by Wise, wire or PayPal, with the custom plan from US$900. Calls happen in English or Hindi, and staff training sessions can be recorded so new captains can watch them later.