Twelve products. One restaurant operating system.
Six products run the shift, four build direct customer channels, and two work across the whole operation. Here is what each one does, and which one a given job needs.
What the Cibus product range is.
Cibus is a restaurant operating system sold as one platform and delivered as twelve products that work from shared menu, order, payment and customer records. Six of them run a live shift, four build direct customer channels, and two work across the whole operation. Restaurants can start with the operating layer they need and add the others later; which products are configured, and in which market, is confirmed in discovery.
Every product, and the job it does.
Each entry is the short version — what the product is, what it actually does during service, and when it is the one you need. Follow a link for the full workflow, the mockups and the product FAQ.
The till surface. Staff sign in with role-checked accounts and open a shift against a counted cash float, then build orders from the menu with structured modifiers and send them to the kitchen. Payment is taken by cash with a denomination breakdown, by Stripe Terminal card-present, or recorded for an external card reader, and the shift closes with a counted reconciliation and a variance check.
Choose it when a member of staff, rather than the diner, is the one entering the order.
A table-specific QR code puts the menu on the diner's own phone with no signup and nothing to install. Several diners at one table share a single order, watch its status change as the kitchen works, and either settle their own share or let one person pay for the table.
Choose it when server time at the table, not kitchen capacity, is the constraint on the shift.
Tickets arriving from POS and QR ordering route to the station that prepares them, so grill, fryer and cold each see only their own work. Each ticket moves through claim, prep, bump and serve with elapsed-time colouring, items can be completed individually when a table finishes unevenly, and the expediter view holds the whole pass in one place.
Choose it when paper tickets and shouting are what break first at peak.
A native iOS and Android app running the same order and calculation logic as the web POS, so a server can open a table, add items, take payment and open or close a shift without walking back to a fixed terminal. It is deliberately honest about connectivity: when the network drops it says so rather than accepting payments that never reach the server.
Choose it when orders are taken on the floor rather than at a counter.
The operator's workspace: menu, modifier, tax and promotion configuration, floor plan and table setup, staff records and role permissions, printer and terminal registration, live order and payment views, and sales, labour and menu reporting. Operators running more than one restaurant switch between them from the same login.
Choose it when the question is configuration or review rather than service.
Payment capture and the money trail behind it: Stripe and Stripe Terminal card-present, cash with denominations, externally recorded card payments, vouchers and coupon codes, tips, and splits across several methods or payers on one order. Totals are calculated in minor units, receipts are issued digitally or on a thermal printer against the order, and the day closes with a reconciliation.
Choose it when reconciliation, rather than order entry, is the part that hurts.
A public ordering site on the restaurant's own branded address, using the same menu, modifiers and payment setup as the counter. Customers choose a pickup window against slot capacity the kitchen controls, or a delivery address inside a configured zone, and follow the order after checkout. Prices and availability can differ by channel where a restaurant needs them to.
Choose it when you would rather own the ordering relationship than rent it.
Campaign preparation that already knows who ordered. A visual segment builder filters on recorded behaviour such as order frequency, recency and consent state, and campaigns go out by email or SMS, with WhatsApp available through Meta-approved templates where it is configured. Marketing consent is tracked per customer, per channel, per restaurant.
Choose it when the customer list is a spreadsheet nobody trusts.
Pick a menu item and Stories prepares caption variants and a composed image sized for the platform, written against a brand voice the operator configures once — tone, hashtags, signoff and words to avoid. Everything is saved as an editable draft: the operator reviews and decides what gets published.
Choose it when the posting habit, not the idea, is what keeps slipping.
The delivery leg the restaurant runs itself. Riders set availability windows and receive dispatched offers with a short accept window, navigate to the drop, and capture photo and timestamp proof at pickup and dropoff. Customers can follow the rider on a map, and riders see their own earnings breakdown.
Choose it when own-delivery volume is real enough to schedule people against.
Analysis contexts over the restaurant's own operating records — a daily briefing, sales and menu analysis, and customer, staff and kitchen views — returned as readable findings with suggested actions. Cibus positions these as recommendations for the operator to review and decide on, never as changes the system makes on its own.
Choose it when the reports already exist but nobody has time to read them.
The workspace for partners who bring restaurants onto Cibus: a guided onboarding flow that creates a restaurant account without engineering support, a portfolio list of the restaurants that partner manages, and commission views by month and by restaurant with payment status. Access is scoped to assigned restaurants.
Choose it when you sell Cibus rather than run a venue.
Which products a given operation reaches for first.
The product range does not change by segment, but the order you adopt it in does. These are the four buyer shapes Cibus is built around.
Three ways into the same platform.
Products answer what each surface does. The platform pages answer how they connect. The solutions pages answer what a given venue type should switch on first.
Choosing between the products.
Do we have to take all twelve products?
No. Restaurants can start with the operating layer they need and add Storefront, Reach, Stories, Rider or partner workflows later. Which products are configured, and in which market, is confirmed in discovery.
Which products should a restaurant start with?
The products that carry a live shift: POS, Kitchen Display System and Payments & Receipts. QR Order & Pay is worth adding where server time at the table is the constraint rather than kitchen capacity. The growth products make more sense once service is settled.
What is the difference between QR Order & Pay and Storefront?
QR Order & Pay is for a diner who is already in the venue: the code is table-specific and the order joins that table's record. Storefront is a public ordering site for people who are not in the room, for pickup or delivery. Both use the same menu and the same payment setup.
Do the products share one menu and one customer record?
Shared menu, order, payment and customer records are what connects them. Configured POS, QR, Storefront, Rider and KDS workflows read the same menu records, with supported local or channel differences where a restaurant needs them.
Are Storefront, Reach, Stories and Rider available now?
Yes — they are part of the current product range. Which of them is configured for a given restaurant depends on the market, the payment and messaging providers in scope, and what discovery agrees.
How is each product priced?
Cibus is quoted after discovery rather than sold from a fixed price list, because the product mix, number of restaurants, hardware and support scope differ per operation. The pricing page explains what shapes a quote.
Not sure which products your operation needs?
A discovery conversation maps how orders arrive, how the kitchen is organised and what your market supports, then sets the product mix against that.