Features

Printable QR menu with multi-language support

Generate one QR per table from the dashboard, print on receipt paper, support TR and EN at once.

A printable QR menu that does not need an app

Most QR menu tools either bury the print function behind a sales call or ship a guest experience that asks for an app install on first scan. MobiTaste prints one PDF with one QR per table, opens the menu in the phone browser, and supports Turkish and English from the same item record. Guests scan, pick, and submit without leaving the page they landed on.

The Tables page generates a PDF with one A6 QR per table. A6 fits on a coaster, a table tent, or a sticker. You print on regular paper or thermal receipt stock, cut, and place. The URL behind each QR includes a unique table token, so a scan from table 4 always lands on table 4’s order, no manual selection.

The token is permanent. When you edit the menu, change prices, or add categories, the printed QR keeps working. That matters because reprint runs cost time you do not have on a Friday night. The QR menu setup guide walks the print step in 20 minutes from sign-up. For the underlying concept, the glossary entry lays it out in 21 words.

Multi-language menu, one editor

Each menu item carries a Turkish text field and an English text field. Prices are shared. Categories carry the same dual-field structure. When a guest opens the menu, they see the locale that matches their phone or the language they pick in the menu header. You type the menu once, in two languages, and the switcher does the rest.

Allergen flags, modifiers (size, sugar, milk), and option groups also localize. A modifier group named “Sıcaklık” in Turkish reads “Temperature” in English on the same scan. The system does not auto-translate; you write each field. That is intentional because machine-translated menus read poorly and lose tone.

You can add a third language later from the dashboard. Pricing across tiers does not change with the number of languages. Starter ships with two locales; you can add Arabic, German, or French on Growth without paying per language.

Live menu, durable URL

The guest URL pattern is /menu/{restaurant-slug}/t/{table-token} and it does not change after launch. Printed QRs are in circulation; the URL is a contract, not a guess. That commitment is built into the product, and it shapes how we ship menu changes (in place, not by minting new URLs).

The menu loads quickly on a 4G phone: images are lazy-loaded, text and prices arrive in the first paint, and the page weight stays light on initial load.

What the editor looks like

Categories are a left-rail list. Items are cards inside each category. Each card holds: name (per locale), description (per locale), price, allergen flags, modifier groups, and an availability toggle. The availability toggle is the “86” function: flip it off mid-service and the item disappears from the guest menu within seconds.

Bulk edits land in a single click. Paste a list of items into the bulk-add field; each line becomes an item under the active category at the default price. You then refine prices and translations. Most cafes type their full menu in under 40 minutes.

Audit log on every change

Every menu edit, price change, and availability flip writes a row to the audit log: who, what, when. Useful when teams grow and you want to know who 86’d the linguine yesterday. The audit log retains 12 months on Starter and Growth, 36 months on Pro, and unlimited on Enterprise.

When this feature is enough

If your restaurant takes orders only at the table and pays at the counter or terminal, this feature alone runs the floor. You do not need a separate POS for the menu, the kitchen screen, or the waiter view. The POS comparison discusses where a POS still belongs.

If you take pay-at-table card payments through your terminal, the menu still does the menu work. iyzico pay-at-table through MobiTaste is on the roadmap; until it ships, your existing card terminal handles money.

Where to start

The fastest path is the 20-minute setup guide. The next is the cafe use case, which describes the smallest-footprint deployment. Pricing math for the full feature set lives on the pricing page, and the features hub lists every adjacent capability.