Scanezi
The code on the table opens the menu in the browser.
Produse Meniu QR
Instrumente pentru ospitalitate Dezvoltare & demonstrații
The menu, the table and the team, in one flow.
We are building a platform for digital menus and operations reachable through a QR code. The customer gets to the information from their phone, and the team manages the menu and the requests.
- 1Cod la masă
- 2Meniu în browser
- 3Solicitare către echipă
Meniu QR
From information to work done.
Alegi
You browse the categories, the options and the information available.
The team takes it from there
Requests and statuses are organised in the venue's own configuration.
Where it earns its place.
Digital menu
Managing items, images and variants.
Interactions at the table
Scenarios for calling a member of staff, asking for the bill, or placing an order.
Operațiuni
Roles and connections shaped to the way the venue works.
Ordering, payments and the link to the management system are confirmed for each deployment.
Meniu QR in detail
What you can do with this project.
Meniu QR is the platform through which a customer scans the code on the table, opens the menu on their phone without installing anything, orders, calls the waiter or asks for the bill. The code is not merely a link: it can be bound to a table, a zone, a location or a service, and that context travels on with every request, so the staff know where it came from.
Underneath, the structure follows what a venue actually looks like: restaurant, locations, zones (indoor, terrace, bar, VIP, outdoor), tables, and over them staff with a role — waiter, bartender, hookah, cook, manager or a role of your own — assigned to tables. An order has seven states, each transition timestamped: new, confirmed, preparing, ready, delivered, paid, cancelled. Calling the waiter has a cycle of its own: pending, picked up, resolved.
The staff do not need a new app: notifications go to Telegram, with rules configured per event — new order, unconfirmed order, a call from a table, negative feedback, successful or failed payment. If nobody picks it up within the set interval (five minutes by default), the notification escalates to the manager.
A QR code with context, not just a link
Four kinds of code: table, zone, location and service. The codes are generated in the platform, can be exported as a PDF for printing, and the link that is built carries the venue and the table with it.
A menu whose translations sit apart from its content
Categories and items have translation tables of their own, so text in another language does not overwrite the original. Machine translation goes first through Anthropic (`claude-sonnet-4`) and, if that key is missing, through Google (`gemini-2.0-flash`). The interface is available in Romanian, Russian and English.
Orders with states and timestamps
Seven states, each with its own moment recorded: confirmation, preparation, delivery, payment. Items within an order have their own state and their own chosen options, which lets part of an order go to the bar and part of it to the kitchen.
Telegram notifications, with escalation
A bot built on grammy, running in webhook mode. Rules are set per restaurant and per event, and if nobody confirms within the configured interval — five minutes by default — the request moves up to the manager. Every notification sent stays in the log.
Payments through the venue's own accounts, not through us
The platform does not sit between the money and the venue: the restaurant uses its own credentials. Adapters are implemented for Stripe, cash and bank transfer. MAIB exists as a skeleton, marked in the code as unfinished.
Features switched on by plan, not all at once
Each restaurant has a set of switches — ordering, calling staff, online payments, feedback, several languages, POS integration, split bill, table booking, promotions. By default only calling staff and cash payment are on; the rest are enabled according to the plan. The table limit is checked when a table is added, not at the end of the month.
Data and operation
What goes into the system. What has to be checked.
- One place for every venue, kept separate from one another
- PostgreSQL through Prisma, with the restaurant identifier on every table and row-level access policies. Administrators sign in through Supabase, staff come in through Telegram, and the customer at the table has no account at all.
- The customer stays anonymous
- The visitor is given a session identifier in an httpOnly cookie, valid for 24 hours, marked `secure` in production. No account is asked for, no phone number, nothing to install. The order and the waiter call are tied to that session and to the table.
- The menu stays the venue's own
- Categories, items, option groups and options are edited by the restaurant. Translations sit in separate tables, so a bad machine translation is corrected without touching the original.
- What is not connected automatically
- The payment types recognised in the code number eight, but written adapters exist for four, and the MAIB one is unfinished. For the others — Moldindconbank, Paynet, Netopia, MobilPay — only the name is in the list, not the integration. It is a distinction to make before promising anything to a venue.
From exploration to deployment
How we prepare a project with Meniu QR.
We map the venue before the menu
Locations, zones, tables, staff and their roles. The QR codes are generated on that structure; if the structure is wrong, the context on every request is wrong.
We choose what goes live first
Ordering, online payment and POS integration are separate switches. For a first venue, calling the waiter and the digital menu are enough to test the flow with real staff.
We finish the payment and POS side, for that particular venue
The MAIB adapter and matching tables to the POS system are work to be done, not configuration. They are estimated against the venue's actual provider, with its credentials and its documentation.
We test with the staff, on a real shift
The flow breaks at the people, not at the code: who confirms, how quickly, what happens when nobody answers. Escalation at five minutes is a starting point that gets calibrated in the venue.
Questions worth settling.
Could a venue use it tomorrow?
No. It is a prototype that is complete in coverage but unfinished and unreleased: a single database migration, dated 4 April 2026, no commits after that day, no automated tests and no public installation. What can be done tomorrow: a demonstration built on a real venue's structure, so the flow can be seen end to end and what is still missing can be estimated.
Does the customer have to install an app?
No. They scan the code and it opens in the browser. They get a session identifier in an httpOnly cookie valid for 24 hours — no account, no phone number, no personal data. The order and the waiter call are tied to that session and to the table on the code.
Can people pay online?
It depends on the provider, and this is worth stating precisely. The Stripe adapter works, as do cash and bank transfer. The MAIB adapter is written as a skeleton and marked in the code as unfinished — it needs the bank's SDK and TLS certificates. For Moldindconbank, Paynet, Netopia and MobilPay only the name is in the list of types, with no integration behind it. Worth keeping in mind: the platform does not hold the money; the venue uses its own credentials.
Does it connect to the restaurant's POS system?
Partly, and the missing part is the one that matters. Adapters are written for iiko (Syrve) and for Poster, with authentication and token exchange implemented, so the menu can be pulled in from their system. Sending the order back is not ready: matching a table in the venue to the table and terminal group in their system is still to be solved. So import yes, full synchronisation not yet.
How do the staff find out that somebody has ordered or called the waiter?
On Telegram, through a bot of its own running in webhook mode — nothing new to install on their phones. Rules are set per restaurant and per event: new order, unconfirmed order, a call to the table or to the manager, negative feedback, staff on a break, successful or failed payment. If nobody picks it up within the set interval, five minutes by default, the request escalates to the manager, and every notification sent stays in the log.
What languages does the menu work in?
The interface is available in Romanian, Russian and English. The menu has separate translation tables for categories and items, so a translation does not overwrite the original text and can be corrected by hand. Machine translation tries Anthropic first (`claude-sonnet-4`) and, if that key is missing, Google (`gemini-2.0-flash`).
Is this the same thing as MEGA QR?
No. MEGA QR generates codes and moves data optically. Meniu QR is a hospitality platform: menu, ordering, calling staff, notifications during a shift, and payments. The only thing they share is the code on the table.
Illustrative example
A call from a table that does not get lost
A usage scenario, with no client data and no commercial results attributed.
The starting situation
A customer scans the code on table 12 in the terrace zone and taps "call the waiter".
How it works
The request comes in tied to the customer's anonymous session and to the table on the code, in the "pending" state. The restaurant's notification rule sends the message on Telegram to the staff assigned to that zone.
Rezultatul
The waiter confirms from Telegram and the request moves to "picked up", then to "resolved". If nobody confirms within the configured interval, five minutes by default, the request moves up to the manager. Every notification stays in the log, so it is possible to see afterwards what was slow.
Ce este necesar:Structura localului introdusă (locație, zone, mese), personal înregistrat în bot cu rolurile lui, reguli de notificare setate pe evenimente și codurile QR tipărite pe mese. Comenzile și plata online sunt comutatoare separate, care pot rămâne închise la primul local.
Ways of working together
Meniu QR, in the context of your organisation.
Access points and local transfer
Codes giving access to public information, instructions or contacts; optical file transfer between compatible devices, with the institution's security policies assessed.
Private companies
We define a pilot around one real process: users, data, integrations, costs and acceptance criteria. Expansion follows once the result has been assessed.
Public institutions and state-owned companies
We establish the requirements for accessibility, hosting, data protection and interoperability. Any connection to services run by Moldova's e-Governance Agency (AGE) or its state information-technology service (STISC) requires eligibility, access and approvals to be validated.
These are adaptation scenarios, not statements about existing contracts or partnerships. The proposed capabilities are confirmed within the project's scope of work.
Discută un pilotPart of an ecosystem.
Agenți vocali AI
Kallina
Construim agenți care preiau și inițiază apeluri, folosesc informațiile afacerii și lucrează cu sistemele tale.
PlatformăConversații și suport
aichat
Un asistent conectat la informațiile afacerii tale, în canalele în care îți scriu clienții.
PlatformăInstrumente în browser
MEGA QR
MEGA QR include un generator de coduri și un instrument de transfer optic.
Instrument publicWhat would you want to work better?
Tell us about your process. Together we decide what is worth building, what we can connect, and how we check the result.