Restaurant and kitchen software for Bangladesh

Restaurant software pages in this market lead with a feature list and bury the shape of the product. This one does it the other way round, because the fit here is genuinely uneven and you will work it out in the demo anyway.

What is strong is the back of house. Recipes, ingredient depletion and plate cost are the deepest part of this module and they are built to a standard that is unusual in this price band. What is thin is the front of house. There is no graphical floor plan and the till does not run table service.

The chain that actually works, end to end, is this one. An order becomes a kitchen ticket. The ticket has lines, each line carries the station that cooks it and its course number, and each line advances through its own states. A completed counter sale raises the ticket automatically, so a quick-service outlet does not key the order twice.

Firing the ticket is the moment that matters. Firing explodes each line's recipe, including nested sub-recipes, applies the wastage allowance, and issues those ingredients out of stock into the ledger. Adding a line consumes nothing; firing consumes.

Modifiers carry their own recipes, so asking for extra cheese depletes the cheese. Plate cost is computed from the exploded recipe against your inventory valuation, in integers throughout rather than in floating point, which is what lets the food cost on a four-hundred item menu actually add up.

The till is a web application installed to the home screen, so a phone is a working till and the camera is the scanner. There is no terminal to buy.

One sale can be settled across several payments: part cash, part card, part mobile wallet. The till tracks the balance due and prefills the next tender. The tender list itself is operator configuration per outlet, not a fixed menu, so you can add the payment methods you actually take.

On a dinner rush with a bad line: When the line drops mid-shift the till keeps ringing sales into a queue on the device itself, and drains that queue on reconnect. A sale that was already committed on the server before the connection died is recognised as the same sale and not charged twice, which is the failure mode that actually costs shops money.

The limit is real and worth planning around. Offline selling is barcode-only, and the device can only sell items it has already scanned online at least once, because that is when it caches the price. There is no bulk pre-download of your catalogue yet. Offline you also cannot sell bundles or redeem loyalty points, and VAT is recalculated on the server when the queue drains rather than on the device. The discount cap is the one to watch: it is enforced by the server, so offline the till will accept a discount above the cashier's cap and the whole sale is then rejected when the queue drains, which is a conversation with the customer after they have left. If your products have no barcodes recorded, offline mode has nothing to sell.

Every completed sale takes a Mushak 6.3 number. At the counter, BizRP allocates a gapless Mushak 6.3 number from an operator-configured series inside the transaction that completes the sale, so a sale cannot reach completed without one, a rollback returns the number rather than burning it, and a void keeps its number and is marked voided. Credit sales land in the same register carrying their sales invoice number from a separate sequence, not from that series, and cancelling a credit invoice does not currently mark its register rows voided. Every line of both channels lands with its taxable value, VAT rate and VAT amount, and the period exports as CSV in NBR column order. Two limits to know: supplementary duty is recorded as zero on every row today, so a business levying SD cannot rely on this register for it, and the buyer's BIN is captured at the counter but not yet on credit sales.

• Kitchen order ticketsShips today

  Orders become kitchen tickets with lines that advance through their own states, routed to the station that cooks them. A completed counter sale raises the kitchen ticket automatically.

• Kitchen boardShips in part

  A kitchen screen shows the open tickets, fires a ticket, advances or voids a line, and links straight to the ingredient issues that firing produced.

  Where it stops. It is a browser page that refreshes when it refetches, not a dedicated always-on kitchen device. There is no bump bar, no push updates and no per-station display hardware. If you want the word for it: a kitchen board, not a KDS.

• Recipes and ingredient depletionShips today

  A menu item carries a recipe, the recipe explodes through nested sub-recipes with a wastage allowance, and firing the ticket depletes those ingredients into the stock ledger. Fire it twice, or replay the same event, and it still consumes once, because the claim is unique in the database rather than guarded by hope.

  Where it stops. Adding a line consumes nothing. Firing consumes. That is deliberate, and it is the distinction to check against how your kitchen actually works.

• Plate costShips today

  A dish has a cost built from its exploded recipe and your inventory valuation, computed in integers throughout rather than in floating point, so the food cost on a menu of four hundred items adds up.

• Modifiers and menusShips today

  Menus belong to an outlet and have sections. Items can carry a price override. Modifier groups have minimum and maximum selections, and a modifier can carry its own recipe, so asking for extra cheese depletes the cheese.

• Kitchen stationsShips today

  Every ticket line carries the station that cooks it, so the grill and the bar are not reading the same list.

• TablesShips in part

  Tables exist as records with a code, a name and a seat count, and a ticket can carry a table and a cover count.

  Where it stops. There is no graphical floor plan and no drag-and-drop table designer. The till does not run table service either: no open tab per table, no course firing from the counter, no waiter app. If your dining room is run off a floor plan today, this is the gap to look at before anything else.

• Dine-in, takeaway and delivery as order typesDoes not ship

  There is no first-class order type. A ticket either has a table or it does not, which you can read as counter versus dine-in, but there is no per-type pricing and no per-type workflow.

• Counter sale raises a kitchen ticketShips in part

  A completed counter sale raises a kitchen ticket automatically, so a quick-service outlet does not key the order twice.

  Where it stops. That link runs one way. The ticket arrives unfired and consumes nothing, because the counter sale already moved the stock. There is no send-to-kitchen button on the till and no table-service flow through it.

• foodpanda and delivery aggregatorsDoes not ship

  There is no integration with foodpanda or any other food-delivery aggregator, and none is close. Channel orders are keyed in like any other order. The courier integrations this platform does have are parcel couriers for e-commerce shipping, which is a different problem.

• How you get the restaurant moduleShips in part

  The restaurant and kitchen module is a real shipped service with its own screens.

  Where it stops. It is not bundled into a published plan and the restaurant option in the signup wizard does not switch it on. It is enabled deliberately for your workspace, so a restaurant should talk to us rather than self-serve and expect a kitchen.

Four things a restaurant buyer will ask about that this does not do.

The last row is the one most likely to catch somebody out, so it is worth repeating in plain words: choosing restaurant in the signup wizard does not switch on the kitchen module or the till. Talk to us rather than signing up and expecting a kitchen.

Most restaurant software in this market sells the till and treats the kitchen as a printer. That gets an outlet trading and it leaves the only number that decides whether the business survives, food cost as a percentage of sales, as something the owner estimates once a quarter from a supplier file and a guess.

1. 01A dish has a recipe, and the recipe has a cost that follows your actual purchase valuation rather than a price typed in last year.
2. 02Firing tickets depletes ingredients, so theoretical consumption exists as a number rather than as an argument.
3. 03A stock count against that consumption gives you variance, which is the number that tells you whether the gap is portioning, wastage or something less comfortable.
4. 04Because it all posts to the same ledger, the food-cost percentage on the management report and the cost of sales in the accounts are the same figure rather than two estimates that never agree.

That is the argument for this product in a restaurant, and it is a back-of-house argument. If the front of house is your problem, the gap list above is the honest answer.