The problem
A small restaurant usually runs on four or five tools that do not talk to each other: a billing machine, a kitchen printer, a notebook for stock, a spreadsheet for the day's cash, and a messaging group for everything else. Each one holds its own version of the same order. By closing time the owner is reconciling numbers instead of reading them.
Zesty is the product I build with my team to replace that stack. The rule behind every screen is the one on the homepage: the guest orders at the table, the kitchen sees it, the counter bills it, and the day closes on the same numbers.
One order, from table to close
Every module reads and writes the same order. That is what lets the later screens, the reports and the AI, be trusted: there is no second copy to disagree with.
Six steps, one record
Order
A guest scans the table QR, or staff take the order on the POS. Both create the same order.
Cook
The ticket lands on the kitchen display, placed on a timeline by when it is due.
Serve
A bumped ticket waits in Ready to run until a server takes it to the table.
Bill
Billing collects cash, UPI, or card. Refunds and manual payments wait for a manager.
Close
Shift desk counts the drawer against what it should hold and closes the day.
Learn
Sales, Analytics, Profit Guard, and the AI read the closed numbers the next morning.
The screens below come from our development workspace: a real cafe menu with a handful of test orders, so the figures are small on purpose. Select any screen to open it full size.
Service
The three screens a guest, a cashier, and a cook touch during service. They are different surfaces over one order.
QR ordering
A guest scans the code on the table and orders from their own phone. The page already knows where they are sitting, shows what has been sent to the kitchen, and can call a server. Staff print the QR kit for a whole location in one sheet.
- The link knows the table
- Each table has its own code, so a guest never types a table number or installs an app.
- One bill per table
- Every round lands on the same bill. Payment opens once the team generates it.
- Staff stay in control
- A QR order waits for a staff member to confirm it before the kitchen starts.
POS
The counter screen handles a walk-in sale and a table order the same way. Items are added with one tap, the sale totals itself with tax and discount, and the payment options sit under the total so the cashier never leaves the screen.
- Built for the rush
- Popular items first, categories and search one tap away, and held bills for orders that pause.
- Every way to pay
- Cash with the change worked out, card, UPI with a QR for the guest, split pay, or pay later.
- Spoken orders
- Staff can speak an order and check the draft before it is sent.
Kitchen display
Most kitchen screens are a grid of tickets. Zesty's default board is a runway, so a cook reads the next fifteen minutes at a glance. A bumped ticket moves to Ready to run, where the timer is how long the plate has waited under the lamp.
- Placed by due time
- Tickets sit on a timeline around now: late, on the pan, and coming in the next fifteen minutes.
- Load against capacity
- Item load shows what is due in each five minutes against what one cook can plate.
- Three layouts
- Runway is the default. Grid and lanes are there for kitchens that prefer them.
Running the shift
What a manager needs while the doors are open: who is on, what is owed, what is left to do, and what is in stock.
Shift desk
Shift desk is one location on one day. While the shift is live it shows who is on, which bills are still open, what is left on the checklist, and what the drawer should hold, with issues and handover notes for the next manager.
- Opening, live, closing
- The page moves through three stages. Closing checks appear on their own an hour before closing time.
- A checklist that holds
- Routine tasks can be skipped with a reason. Safety checks cannot.
- Cash counted, not assumed
- The drawer is counted against the expected amount and any variance is recorded against the shift.
Stock
Inventory is a work queue, not a list. Each material shows where it stands and what has to happen next, and the value on hand and the week's wastage stay in view at the top.
- Sorted by urgency
- Act now, counting, purchasing, receiving, and stable. The queue starts with what needs a person.
- Three numbers per material
- Stock on hand, the minimum, and the theoretical figure worked out from sales.
- Guarded adjustments
- Changes above a guardrail stay pending until a manager records the verification.
Knowing the numbers
Three views of the same closed orders: one to reconcile, one to explain, and one to hand to the accountant.
Sales
Sales is for reconciling: daily close, revenue trend, orders and refunds, items, channels, payments, and tax. The readout on the right states what changed in plain words and whether the books balance.
- Gross to net
- Revenue is broken down through discounts and refunds, so the net figure can be traced.
- Compared by default
- Every view sets this period against the previous one.
- A confidence label
- A jump built on six orders is marked low confidence instead of being shown as a trend.
Analytics
Where Sales answers what happened, Analytics answers why. An owner starts from a question, not from a chart type, and can save the view or turn a finding into a decision.
- Seven starting views
- Executive takeaways, demand by hour, service pressure, retention, item mix, location variance, and staff comparison.
- Measure, grain, split
- Any view can change what is measured, by which period, and split by what.
- Why it changed
- Causes are ranked by impact and link to the orders behind them.
Reports
Reports are the fixed formats an owner or accountant asks for every week. They are computed from settled orders only, so a report never moves after the day is closed.
- Ten reports
- From daily sales and payment clearing to GST liability by slab, menu profitability, and profit and loss.
- Every one exports
- Each report downloads as CSV, one at a time or all together.
- Sent on a schedule
- Daily or weekly by email, in each location's own time.
Protecting the margin
Most restaurant software reports what was sold. Profit Guard looks for what was lost.
Profit Guard
Profit Guard watches menu margins, payments, discounts, reviews, channels, and locations, and turns each signal into an action with an owner. When the data is not good enough, it says so: in this workspace no recipe costs are entered yet, so instead of guessing at margins it asks for recipe costing first.
- Ranked by rupees
- Leaks are ordered by what they cost, not by percentage, so the list starts with the biggest.
- A trail for every action
- Check the numbers, approve the change, make the change, then check the result after 14 days.
- Eleven guardrails
- From checking a menu price to drafting a purchase order. All of them start on manual.
AI that shows its work
The assistant is useful only if an owner can check it. Every answer names its source, every tool is metered, and nothing changes in the records until a person with the right permission reviews it.
Ask Zesty
Owners ask in plain language, by typing or by voice note: why did sales drop this week, which items should I reprice, what should I reorder. The daily business pulse is free and uses no AI action.
- Your own numbers
- Answers are built from the restaurant's orders, stock, and bills, with the source report attached.
- Says what it cannot know
- Asked what to reprice without recipe costs, it answers from sales and states that margins are missing.
- Metered
- Each answer uses one AI action from the plan's credit, and the balance is always shown.
Ten tools, each metered and logged
Ask Zesty
Questions answered from your own numbers, with the report attached.
Assistant chat
Talk a question through, or send a voice note.
Invoice scan
Reads a supplier bill into lines a person checks before saving.
Daily brief
What is worth knowing each morning, sent to the owner.
Demand forecast
How busy tomorrow could be, shown as a band, not a single number.
Reorder suggestions
Draft purchase orders and prep lists when stock runs low.
Suggested actions
Zesty drafts the work. A person approves or undoes it.
Kitchen ready times
Predicted ready times and the tickets at risk.
Feedback themes
What guests keep saying, counted from reviews.
Location comparison
Every location ranked by its own scorecard.
Autonomy
The hard part of AI in a business tool is not the answer. It is deciding what the software may do on its own. Zesty makes that an explicit setting the owner controls, with every action logged and reversible.
- Three levels
- Suggest, approve, and auto, set per tool and per organisation. Every tool starts at suggest.
- Money and guests stay manual
- Anything that moves money or touches a guest cannot be set to auto at all.
- Logged, not recorded
- The activity log shows what was done and by whom, never what was said.
Technical approach
Zesty is a multi-tenant SaaS. An organisation owns one or more locations, and each location has its own menu, tables, stock, and shift. Owners, managers, kitchen, floor staff, and guests each get their own surface over the same data, with permissions scoped per location.
Orders move through a single pipeline: create, kitchen queue, ready, serve, bill, settle. Stock moves as items sell, reports are computed from settled orders only, and features roll out per location so a new module can be tried in one outlet before the rest.
AI usage is metered per plan, and the forecast is deliberately modest: a same-weekday baseline adjusted for festival days, with a note on what it does not account for yet.
Outcome
A restaurant can take a QR order, cook it, bill it, close the shift, and read the day's numbers without leaving Zesty or typing anything twice. The product is live at zesty.id with a 14-day pilot, and we demo it by running one table from QR order to day close.