Tools for hospitality Development & demonstrations

The menu, the table and the team, in the same flow.

We are building a platform for digital menus and QR-accessible operations. The customer reaches information from the phone, and the team manages the menu and requests.

Discuss a demonstration How it works See an example

1Code on the table
2Menu in browser
3Request to the team

Explanatory diagram ·QR Menu

QR Menu

From information to work done.

Scanezi

The table code opens the menu in the browser.

Alegi

You browse the available categories, options and information.

Team continues

Requests and statuses are organised in the venue configuration.

Where it becomes useful.

Digital menu

Management of products, images and variants.

Table interactions

Scenarios for requesting staff, the bill or the order.

Operations

Roles and connections adapted to the venue’s way of working.

Orders, payments and the connection with the management system are confirmed for each implementation.

QR Menu in detail

What you can do with this project.

QR Menu is the platform through which a customer scans the code on the table, opens the menu on the phone without installing anything, orders, calls the waiter or asks for the bill. The code is not just a link: it can be linked to a table, an area, a location or a service, and that context continues with each request, so the staff knows where it comes from.

Behind the scenes, the structure follows how a venue actually looks: restaurant, locations, areas (indoor, terrace, bar, VIP, outdoor), tables, and above them staff with a role — waiter, bartender, hookah, chef, administrator or own role — and allocation to tables. The order has seven statuses with a timestamp for each transition: new, confirmed, in preparation, ready, delivered, paid, cancelled. The waiter call has its own cycle: pending, taken, resolved.

Staff do not need a new app: notifications go through Telegram, with rules configured by event — new order, unconfirmed order, table call, negative feedback, successful or failed payment. If no one takes it within the set interval (five minutes by default), the notification escalates to the administrator.

QR code with context, not just a link

Four code types: table, area, location and service. The codes are generated in the platform, can be exported as PDF for printing, and the built link carries the venue and the table with it.

Menu with translations separate from content

Categories and products have their own translation tables, so text in another language does not overwrite the original. Automatic translation goes first through Anthropic (`claude-sonnet-4`), and if that key is missing, through Google (`gemini-2.0-flash`). The interface is in Romanian, Russian and English.

Order with states and timestamp

Seven states, each with its recorded moment: confirmation, preparation, delivery, payment. The products in the order have their own state and their own selected options, which allows part of the order to go to the bar and another part to the kitchen.

Telegram notifications, with escalation

Bot built on grammy, in webhook mode. Rules are set per restaurant and per event, and if no one confirms within the configured interval — five minutes by default — the request goes up to the administrator. Each notification sent remains in the log.

Payments with the venue's accounts, not through us

The platform does not intermediate the money: the restaurant uses its own credentials. Adapters for Stripe, cash and transfer are implemented. MAIB exists as a scaffold, marked in the code as unfinished.

Functions turned on by subscription, not all at once

Each restaurant has a set of toggles — order, staff call, online payments, feedback, multiple languages, cash register integration, split bill, table reservation, promotions. By default, only staff call and cash payment are turned on; the rest are activated according to the plan. The table limit is checked when adding, not at the end of the month.

Data and operation

What enters the system. What needs to be checked.

One place for all venues, separated from each other: PostgreSQL through Prisma, with the restaurant identifier on all tables and row-level access policies. Administrator authentication is done through Supabase, staff enter through Telegram, and the customer at the table has no account at all.
The customer remains anonymous: The visitor receives a session identifier in an httpOnly cookie, valid for 24 hours, marked `secure` in production. It does not ask for an account, does not ask for a phone number, does not install anything. The order and the waiter call are tied to that session and to the table.
The menu remains the venue's: Categories, products, option groups and options are edited by the restaurant. Translations are kept in separate tables, so an incorrect automatic translation can be corrected without touching the original.
What is not connected automatically: The payment types recognised in the code are eight, but written adapters exist for four, and the one for MAIB is unfinished. For the others — Moldindconbank, Paynet, Netopia, MobilPay — only the names are in the list, not the integration. It is a distinction that must be made before promising anything to a venue.

From exploration to implementation

How we prepare a project with Meniu QR.

We map the venue before the menu

Locations, areas, tables, staff and their roles. QR codes are generated on this structure; if the structure is wrong, the context in each request is wrong.

We choose what starts from the beginning

Orders, online payment and cash register 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 cash register part, for that venue

The MAIB adapter and matching tables with the cash system are work to be done, not configuration. It is estimated based on the venue’s specific provider, with its credentials and documentation.

We test with the staff, on a live shift

The flow breaks at people, not at code: who confirms, in how much time, what happens when nobody answers. Escalation at five minutes is a starting point that is calibrated in the venue.

Questions worth clarifying.

Can a venue use it tomorrow?

No. It is a prototype complete in coverage, but unfinished and not launched: a single database migration, from 4 April 2026, no commits after that day, no automated tests and no public installation. What can be done tomorrow: a demonstration on the structure of a real venue, so that the end-to-end flow can be seen and what is still missing can be estimated.

Does the customer need to install an app?

No. The code is scanned and it opens in the browser. It receives a session identifier in an httpOnly cookie valid for 24 hours — no account, no phone, no personal data. The order and the waiter call are tied to that session and to the table on the code.

Can you pay online?

It depends on the provider, and it is worth saying exactly. The Stripe adapter is functional, as are cash and 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 there are only the names in the types list, without integration. Important to note: the platform does not hold the money; the venue uses its own credentials.

Does it connect to the restaurant cash register?

Partially, and the missing part is the one that matters. Adapters have been written for iiko (Syrve) and for Poster, with authentication and token exchange implemented, so the menu can be pulled from their system. Sending the order back is not ready: matching the table in the venue with the table and terminal group in their system is still to be resolved. So import yes, full synchronisation not yet.

How does the staff know that someone has ordered or called a waiter?

On Telegram, with a custom bot in webhook mode — without a new app to install on their phones. Rules are set per restaurant and per event: new order, unconfirmed order, call to table or administrator, negative feedback, staff on break, successful or failed payment. If nobody takes it within the set interval, by default five minutes, the request escalates to the administrator, and every notification sent remains in the log.

In which languages does the menu work?

The interface is in Romanian, Russian and English. The menu has separate translation tables for categories and products, so the translation does not overwrite the original text and can be corrected manually. Automatic translation first tries Anthropic (`claude-sonnet-4`) and, if that key is missing, Google (`gemini-2.0-flash`).

Is it the same as MEGA QR?

No. MEGA QR generates codes and transfers data optically. Meniu QR is a hospitality platform: menu, ordering, calling staff, shift notifications and payments. The only thing they have in common is the code on the table.

Illustrative example

A call from the table that does not get lost

A use case, without client data or attributed commercial results.

Initial situation

A customer scans the code on table 12 in the terrace area and presses “call the waiter”.

How it works

The request enters linked to the customer's anonymous session and to the table in the code, with the status “pending”. The restaurant notification rule sends the message on Telegram to the staff assigned to that area.

Rezultatul

The waiter confirms from Telegram and the request moves to “taken”, then to “resolved”. If nobody confirms within the configured interval, by default five minutes, the request goes up to the administrator. Every notification remains in the log, so it can be seen later what caused the delay.

What is required:The structure of the premises entered (location, areas, tables), staff registered in the bot with their roles, notification rules set by events and QR codes printed on tables. Online orders and payment are separate switches, which may remain off at the first premises.

Collaboration possibilities

Meniu QR, in the context of your organisation.

Access points and local transfer

Codes for access to public information, instructions or contacts; optical transfer of files between compatible devices, with assessment of the institution's security policies.

Private companies

We define a pilot around a real process: users, data, integrations, costs and acceptance criteria. Expansion follows after evaluating the result.

State institutions and companies

We establish the requirements for accessibility, hosting, data protection and interoperability. Any connection to AGE or STISC services requires validation of eligibility, access and approvals.

These are adaptation scenarios, not statements about existing contracts or partnerships. The proposed functions are confirmed within the project scope.

Discuss a pilot

Part of an ecosystem.

AI voice agents

Kallina

We build agents that answer and place calls, use the information the business already holds, and work with your systems.

Platform

Conversations and support

aichat

An assistant connected to your business information, in the channels your customers actually write to.

Platform

In-browser tools

MEGA QR

MEGA QR includes a code generator and an optical transfer tool.

Public instrument

What 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.

Let's talk