Shokava — accounting and automation system for cafes

01Project overview

Shokava is a web application for accounting and automation in cafes, which we designed and built under the product name BillMaster. It is a full-featured SaaS system for HoReCa: a small venue signs into its dashboard with a login and runs everything in one place — order taking, bills and receipts, the menu and its items, inventory and recipe costing, staff roles, and reporting. Instead of notebooks, scattered spreadsheets, and verbal arrangements, a cafe gets a single tool where every action is recorded and reflected in numbers.

The idea grew out of a clear market pain. A small cafe or kiosk usually cannot afford a heavy enterprise-grade point-of-sale system — and at the same time it outgrows pen-and-paper bookkeeping. Orders are jotted into a notebook, stock levels live in the buyer\'s head, nobody really calculates the cost of a dish, and at the end of a shift no one can say with confidence how much was actually earned or where the products went. Shokava closes exactly this gap: it gives the venue the discipline and transparency of a large system, but in the form of a lightweight web app that opens in a browser.

We ran the project end to end — from the data model and server logic to the dashboard interfaces, the order-taking screen, and reports. Below we break down what problem Shokava solves, how its key modules work — orders, menu, inventory and costing, roles and access — and which engineering decisions turned the everyday chaos of a small cafe into a managed process with clear numbers.

It is worth stating the product\'s focus up front. Shokava is not an \"electronic menu\" and not just a pretty waiter interface. Its main value sits deeper: in cost and stock control, in shift transparency, and in speed of service. These three things determine whether a small venue survives, and the entire system was built around them.

02Context and the task

When we examined the task together with the owner, it turned out that \"accounting\" in a typical small cafe is a set of loosely connected manual practices. Each of them seems tolerable on its own, but together they create a constant leak of money and time. Here are the pain points we surfaced:

• Orders in a notebook. The waiter writes items on paper or keeps them in memory and passes them to the kitchen verbally. Mistakes, forgotten items, \"I didn\'t order that\" disputes — all of this is the norm, not the exception.
• Cost is unknown. Nobody calculates which ingredients a dish is made of and in what amounts. The menu price is set by gut feeling, and the real margin stays a mystery until the venue slips into the red.
• Inventory lives apart from sales. Stock is counted by hand and rarely, and write-offs are not tied to dishes sold. As a result, a key ingredient \"suddenly\" runs out at peak hours, or forgotten supplies spoil.
• The shift is opaque. At day\'s end it is hard to say how much revenue came through, which items sold, what was written off, and whether the till balances. Staff control rests on trust rather than data.
• No separation of rights. Either everyone has access to everything, or everything depends on one person. Both are dangerous: the first for money and data, the second for continuity of work.

The task was framed like this: pull these scattered practices into a single system where orders, inventory, costing, and reporting are connected and update automatically. At the same time the system has to stay simple enough for a venue without its own IT department, and strict enough that each employee has exactly the access they need — no more.

A separate layer of the task is speed on the floor. There are no spare seconds in a cafe: if order taking or printing a receipt lags, service suffers and the queue grows. So from the very start we treated the waiter interface not as a \"data entry form\" but as a working tool used in a hurry, with one hand, between tables.

03Project goals

The task produced concrete product and engineering goals that we kept in mind at every stage:

• A single source of truth. Orders, menu, inventory, costing, and reports live in one database and are connected to each other, rather than scattered across notebooks and files.
• Cost control. Every dish is broken down into ingredients with consumption norms, so the system always knows the real cost of a portion and the margin on it.
• Automatic write-offs. Selling a dish reduces ingredient stock automatically — without a separate manual operation.
• Roles and access. Waiter, cook, manager, and administrator each see and can do exactly what their role requires. Sensitive functions are protected.
• Speed of service. Taking an order and working with a bill must be fast and resilient to haste, with no extra steps or waiting.
• Shift transparency. At any moment you can see what was sold, what was written off, how much revenue came in, and what stock remains — without manual reconciliation at day\'s end.
• Browser availability. No heavy software to install: log in to the dashboard and work from any device in the venue.

These goals shaped not only the functionality but the character of the interfaces: technical, calm, free of decorative noise, with a focus on doing any frequent operation in as few clicks as possible.

04What we did

Shokava assembles the work of a cafe into several connected modules that together cover the whole life cycle — from taking an order to a shift report:

These modules are built not as separate apps but as parts of one whole: the menu feeds orders, orders are linked to costing, costing moves inventory, and inventory and sales flow into reports. It is this connectedness that turns a set of features into an accounting system.

05Solution architecture

Shokava is a server-side web application with authorization: an employee signs into the dashboard with their login and works with the data of their own venue. Logically the system is split into several connected layers, and that connectedness is its main engineering value.

• The data layer. A single model describing the venue, employees and their roles, the menu and categories, ingredients and consumption norms, orders and their items, inventory movements. Everything is linked by references, so the system always knows how one thing affects another.
• The operations layer. The business logic of orders and bills, cost calculation from ingredients, automatic write-offs on sale, aggregation of data into reports. This is where the rules a cafe runs by live.
• The access layer. Authorization and rights separation: which role sees what and may do what. Sensitive operations — changing prices, access to reports, inventory management — are closed off to those who do not need them.
• The interface layer. Different working screens for different roles: fast order taking for the waiter, a dish queue for the kitchen, analytics and settings for the manager and administrator.

The key architectural decision is linking a sale to inventory through costing. A menu dish is tied to its costing recipe, the costing to ingredients and their norms, and ingredients to stock levels. When a dish is sold, the chain fires by itself: the system knows the cost of the portion and automatically writes off the products consumed. Without this link, accounting would fall apart into separate pieces that never reconcile — and we made it the backbone of the system.

06How an order flows

From the floor\'s point of view, an order\'s path comes down to a few steps, and most of the accounting work happens without staff involvement:

• 1. Opening an order. The waiter opens an order at a table and adds items from the menu. The contents can be changed during service — add dishes, remove them, adjust quantities.
• 2. Passing to the kitchen. Items go into work: the cook sees what to prepare, without verbal hand-off or lost slips of paper.
• 3. Writing off ingredients. Behind every sold item stands a costing, so the system automatically reduces the stock of consumed products.
• 4. Bill and receipt. When ready, the order is closed: a bill and receipt are produced, revenue is recorded, and the order moves into history.
• 5. Appearing in reports. A closed order automatically lands in the shift summaries — by revenue, items sold, and inventory movement. No manual reconciliation at day\'s end.

An important detail — every action is tied to an employee. Because work is done under a login, the system knows who opened the order, who ran it, and who closed it. This both disciplines staff and gives the manager a footing when reviewing disputed cases: for any order you can see what happened in it and who was responsible.

07Key capabilities

Let us break down what makes Shokava not an \"electronic menu\" but a genuine accounting and automation system for a venue.

Taking and running orders

The heart of the system is the waiter\'s work. An order is opened at a table, items are added from the menu in a couple of taps, and the contents are changed freely during service. The screen is designed to be convenient in a hurry: frequent actions are in plain sight and superfluous steps are removed. The faster order taking goes, the shorter the queue and the higher the table turnover.

Bills and receipts

An order is closed by producing a bill and a receipt — recording revenue and moving the order into history. This is both convenient for the guest and the point at which sales data finally enters the books: from this moment the item is counted as sold, the ingredients as written off, and the revenue as recorded.

Menu and items

A catalog of dishes and drinks with categories, prices, and descriptions — the foundation everything else rests on. The menu is easy to keep current: add an item, change a price, hide what is not available today. Each item is linked to its costing, so a change in the menu is immediately reflected correctly in both cost and inventory.

Inventory and costing

The key accounting module. For each dish a costing is defined — which ingredients it is made of and in what amounts. From this the system computes the real cost of a portion and automatically writes off products on sale. Stock levels update by themselves, on the fact of sales, rather than through rare manual stocktakes.

Roles and access

Waiter, cook, manager, administrator — each role has its own screen and its own set of rights. The waiter takes orders, the cook sees the dish queue, the manager works with the menu, inventory, and reports, and the administrator manages the venue and staff. Sensitive functions are closed off to those not entitled to them.

Management dashboard and reports

The manager and owner see the venue in numbers: revenue, sales by item, stock on hand. Reports are assembled automatically from real operations, so they can be trusted — this is not a manual summary that is easy to tweak, but a reflection of what actually happened over a shift or a period.

08Costing and recipes

If there is one function worth introducing an accounting system for in a small cafe, it is cost control. Without it the venue works blind: menu prices are set intuitively, and nobody knows the real margin until the money starts running out. Shokava makes cost visible and precise.

The mechanics are simple and strict. Every dish is broken down into ingredients with consumption norms: so many grams of one product, so many milliliters of another, so many units of a third. Knowing the purchase prices of ingredients, the system calculates the portion cost automatically. That means the figure most important to catering is always visible — how much it costs to prepare a dish and how much the venue earns on it.

This changes how a cafe is managed in a qualitative way. The owner sees which items are genuinely profitable and which drag things down; can deliberately change a price or a recipe; notices when rising purchase prices have eaten the margin — not after the fact through losses, but immediately in the numbers. Costing stops being a paper formality and becomes a working pricing tool.

09Inventory and automatic write-offs

The second half of Shokava\'s accounting value is inventory linked to sales. In most small venues stock and the till live in parallel universes: they sell by one measure, write off by another, count stock once a month, and are surprised by the discrepancy. We joined these universes together.

This works through the same costing. Since every dish is broken down into ingredients with consumption norms, selling a portion automatically reduces the stock of those ingredients. No separate manual write-off operation is needed — inventory moves by itself, on the fact of real sales. Purchases, in turn, are entered as receipts, increasing stock. As a result, the balance of each product at any moment reflects the real picture, not the last manual stocktake from a week ago.

The applied value here is very concrete. First, stock control: you can see what is running out and when, restock in time, and avoid stopping the kitchen at peak hours. Second, loss control: a gap between what should have been written off by sales and what is actually on the shelf is a direct signal of spoilage, errors, or abuse. The system does not accuse anyone, but it makes such gaps visible — and what is visible is manageable.

10Roles, access, and security

A cafe is a team with differing responsibilities, and giving everyone the same access is dangerous. So Shokava has role-based rights separation built in from the start, and it is not a cosmetic setting but part of the architecture.

The roles reflect the real structure of a venue:

• Waiter — takes and runs orders, builds bills. Sees what is needed on the floor and has no access to inventory, pricing, or reports.
• Cook — sees the dish queue and the contents of orders, works with the kitchen part of the process.
• Manager — manages the menu, inventory, and costing, sees revenue and stock reports, controls the shift.
• Administrator — configures the venue and staff, manages roles and access, has the full picture.

Behind this stands the principle of least privilege: each person has exactly the rights their work requires — no more. This protects both data and money: a waiter cannot rewrite prices or scrub a report, and access to sensitive functions stays with those responsible for them. And because work is done under an individual login, every action in the system is tied to a specific employee — which both disciplines staff and gives shift transparency when there is a need to figure out what happened.

11Management dashboard and reports

For the product to stand on its own, a waiter screen is not enough — you need a dashboard where the manager and owner see the venue as a whole and run it. The dashboard brings together menu, inventory, and costing setup, staff and role management, and above all reporting based on real operations.

The reports answer the questions a cafe asks every day: how much revenue came through a shift, which items sold best, what was written off, what stock remains. Since all of this is assembled automatically from orders and inventory movements, the numbers can be trusted — they reflect what actually happened rather than a manual summary that is easy to distort.

In essence, the dashboard is a \"control panel\" over everything the system does in the background. It covers everyday management scenarios without outside help: add a dish to the menu and immediately set up its costing, register a stock receipt, move an employee to another role, see how the shift is going, review a disputed order. Shift transparency here is not an abstraction but a concrete screen the manager watches throughout the day.

12Speed of service

In catering, time is money in the most literal sense: the faster service goes, the more guests and the higher the table turnover. So speed on the floor was for us not a nice bonus but a separate project goal that the interface was sharpened around.

We assumed the waiter works in a hurry, between tables, often with one hand. That means frequent actions — open an order, add an item, close a bill — must be done in as few taps as possible and be resilient to haste. The menu is structured by categories so the right item is found quickly; the order contents change on the fly; closing a bill does not require extra confirmations where they are not needed.

Importantly, interface speed does not conflict with the strictness of accounting. While the waiter simply takes an order quickly, the system does all the bookkeeping in the background — linking items to costings, preparing write-offs, accumulating data for reports. The staff do not feel the weight of an accounting system, yet the venue still reaps all its fruit. This balance — fast for the floor, strict for the books — is one of the main results of the project.

13Technology stack and infrastructure

Shokava is a web application with server logic, a database, and authorization, deployed as a standalone product on its own infrastructure, behind Cloudflare and with a valid TLS certificate. We assembled a tidy isolated environment for it — safer and simpler to maintain.

• Backend — server logic for orders, bills, costing, and inventory movements, aggregation of data into reports, authorization and rights checks on every action.
• Data — a connected venue model: employees and roles, menu and categories, ingredients and consumption norms, orders and their items, inventory movements.
• Interfaces — working screens per role: fast order taking, the kitchen queue, menu and inventory management, dashboard and reports.
• Infrastructure — an isolated environment behind Cloudflare with DNS, TLS, and perimeter protection; dashboard access by login only.

14Design and UX

An accounting system sells not beauty but confidence: the staff must trust the interface in a hurry, and the owner must trust the numbers in the reports. So we made Shokava\'s interfaces calm, technical, and functional, free of the decorative noise that only gets in the way of work.

The approach to UX followed directly from the roles. The waiter screen is optimized for speed: large, clear elements, frequent actions in plain sight, the fewest steps to a result. The manager dashboard, on the contrary, is for thoughtful work with data: here what matters is readable tables, clear summaries, and convenient menu and costing setup. One product, but different modes of work for different tasks.

Special attention went to keeping the complexity of accounting from leaking out where it is not needed. A waiter does not need to see costings and cost prices — they need to take an order quickly; all the accounting machinery works behind the scenes. And where the data matters — in the dashboard and reports — we, on the contrary, made it as clear as possible. A good interface for an accounting system is one that shows each role exactly as much as it needs, and not a gram more.

15How we worked

We ran the project in sequential stages, each with a tangible result:

• Research. We studied how accounting is really arranged in a small cafe: an order\'s path, work with inventory, pain points, staff roles, and the scenarios of each of them.
• Data model. We designed a connected schema — venue, roles, menu, ingredients and norms, orders and items, inventory movements — on which all the logic rests.
• Accounting core. We built order taking, bills and receipts, cost calculations and automatic write-offs, authorization and rights separation.
• Reporting and dashboard. We made the management dashboard and summaries of revenue, sales, and stock, assembled automatically from real operations.
• Trial and launch. We ran the system through real shift scenarios, polished speed on the floor, and deployed the product behind Cloudflare with authorization and TLS.

At every step we checked decisions against the real work of a cafe: an accounting system is valuable exactly to the extent that it fits the venue\'s living process, not an abstract scheme.

16Result

The outcome is not an \"electronic notebook for the waiter\" but a standalone system for accounting and automation of a cafe, in which orders, inventory, costing, and reporting are linked into a single whole and work for the owner.

• Accounting is gathered in one place — no notebooks or scattered spreadsheets, everything is counted and reconciled by itself.
• The cost of every dish is visible and precise — pricing and margin stop being guesswork.
• Inventory moves automatically with sales — stock levels stay current and losses become visible.
• Rights separation protects data and money, and individual logins make the shift transparent.
• A fast waiter interface speeds up service without sacrificing the strictness of accounting.

17Takeaways

Shokava is an example of how the right data model turns the everyday chaos of a small venue into a managed process. The most valuable thing here is not that the system \"takes orders\" but how its parts are linked: a sale moves inventory, inventory and costing give cost, and all of it adds up to an honest report. It is this connectedness that distinguishes a true accounting system from a pretty menu with a \"pay\" button.

For us this was a project at the intersection of product thinking and engineering discipline: we had to understand the real work of a cafe and at the same time build a strict yet lightweight system used in a hurry and trusted in its numbers. If you need an accounting system, a SaaS for a specific niche, or a complex web application with roles, data, and clear analytics — we know how to bring such things to launch.