The product
Take the payment, run the floor, count the stock, fill the calendar, pay the team and close the books, in one place, on one set of records.
Front of house to back office
The register a cashier works on, the board the floor runs on and the ledger an accountant reads are the same system reading the same sale.
Open ticket · Table 4
Items, modifiers, discounts and tender on one screen.
Dining room
Kitchen display
Tables and tabs stay open until they are paid, and tickets go to the kitchen screen.
Journal entry · Sale
BalancedPosted by the sale itself. Nothing was exported.
The sale posts itself to a double-entry ledger, so nothing waits on an export.
One sale, every record
Ringing an item touches the payment, the stock, the customer, the shift and the ledger. When those live in five products, somebody reconciles them by hand every month.
Ticket 1043 · closed
PaidOne sale
Flat white ×2, toast, sandwich, rung at the counter.
Module by module
Turn on what the business uses. Everything below is built today. Nothing here is a roadmap item.
Payments
The register and card payments come set up together, so each sale and its payment sit on one record. Cards are taken in person on our own terminal.
The hardware Batch runs onRestaurant floor
Open a check against a table or a tab at the bar, seat and split it as the party changes, and fire the ticket to a kitchen screen instead of a printer.
Restaurants and barsInventory
On-hand quantities are kept location by location and variant by variant, purchase orders run from the order through to receiving, and a count shows expected against counted line by line.
Retail use casesScheduling
Customers pick from times that are genuinely open, because availability is computed per provider in the location’s own timezone and the overlap is refused by the database, not by the screen.
Booking pages in MarketingTeam and payroll
One login per person, one role deciding what they can open, shifts and breaks on the clock, tips declared at the end of the night, and payroll runs with a line for each person.
One team, every locationBooks and reporting
Sales, labour, item and tender reporting reads the live records rather than last night’s export. Underneath it is a double-entry general ledger that the sale, the refund, the stock movement and the payroll run all post to.
Why one systemMarketing
Segments come from your own records, texts and emails go to a segment, and consent is checked for every recipient before anything sends.
All of marketingKiosk and menu boards
A tablet becomes a self-order kiosk whose orders arrive open at the register for your team to take payment, and the menu on the screens behind the counter is the menu you already maintain.
Cafés and countersMulti-location
Each location keeps its own stock, its own drawer and its own numbers. Roles, customers and the ledger are the business’s, and the reports read either way.
See pricingUnder the hood
Payments, reporting, the ledger and permissions share one core, so there is nothing to bolt on.
Token
tok_3Kq…9f
On the sale
•••• 4242
Terminals encrypt the card at the reader, and the sale record keeps the last four digits. The card number is never stored.
Sales, labor and item reporting reads the live sale and time-clock records rather than an overnight export.
A refund or void is stored against the original sale, so a report shows what was taken and what came back.
A person’s role decides what they can open. Each business’s data is kept separate, and the database adds row-level isolation as a second check behind the application.
Start with the register