Protection lives in the database and on the server, not only in the buttons.

Every user sees only the venues where they hold a valid membership and a sufficient role. Changing the address in the browser or the contents of a request does not open someone else's data — the check is done by the server and by the database itself, through row-level rules (Row Level Security).

Non-existent, malformed and foreign venue addresses receive the same response, so nothing about what exists can be inferred from a refusal.

Staff work in the request queue. A manager has delegated, limited access to content. The owner is the venue's administrator. Permissions are not enforced by hiding menu items but by checking identity, membership and role on the server, with pre-approved database operations.

• Signed-in identity and venue membership
• Role checked on the server and in the database
• Only approved operations on data
• A check at the level of every page

The guest creates no account, but cannot flood the team either. Every table has a unique, unpredictable link. The server checks that the venue and table are active and respects opening hours when enabled.

It then applies repeat rules: the same request cannot be active twice, there is a maximum number of active requests per table, a pause before repeating the same type, a gap between different types and a limit within a time window.

The owner can switch individual actions off and mute a table when necessary.

Accepting and completing a request is not a change in the browser but a record in a database that allows only valid transitions. That is why two people cannot own the same request at once, and the status the guest sees matches the real state.

Sensitive venue settings are changed through audited operations with pre-approved fields, not free writes from the browser. Concurrency protection prevents one stale session from silently overwriting newer changes made in another.

The guest leaves no name, phone number or account. A request carries the venue, zone, table, request type and times — operational data of the venue, not a guest profile. The website you are reading uses no tracking and no third-party analytics.

Odazivo is developed with automated type checks, database security tests, role and access tests, end-to-end tests of the guest, team, manager and owner flows, verification of the database migration history, and scanning of the code and shipped bundles for secrets. That is not a marketing message; it is how the work is done.