Development Agency
Contact Sign in Get a project quote

Service

QR menu software development

For venue operators who want a QR menu that behaves like their venue, with the right menu at the right table at the right hour, and optionally takes the order, rather than a PDF behind a code or a generic ordering app that charges per order.

Get a project quote See the software package

The problem

What goes wrong today

Where it usually starts

Most QR menus are a sticker that opens a PDF.

  • The PDF was exported from a design file in the spring, it is three megabytes on a phone with one bar of signal, and it still lists the brunch dishes at nine in the evening.
  • A diner with a nut allergy scrolls through forty items looking for a symbol that was never added.
  • At a hotel the same code on the poolside tables opens the restaurant's dinner menu, and at a food hall with six kitchens the diner has to find out which code belongs to which counter.
  • When the kitchen runs out of the special, the menu does not know, so the waiter explains it to every table until close.

Where it gets harder

Where venues have moved to order-to-table, the usual answer is a marketplace app that takes a cut of every order, owns the customer's details and sends the kitchen a stream of tickets with no sense of which table is still waiting on a starter.

  • Guests who want the bill wave at a waiter who is behind the pass.
  • The manager has no idea which items are looked at and never ordered, whether the lunch menu is read at all after two o'clock, or which tables are generating the most call-waiter requests, because none of that is measured by a PDF.

Scope of the service

What the build covers

A custom QR menu build normally covers:

  • A menu model with sections Items, prices, images where wanted and the allergen and dietary tags your kitchen records
  • Menu versions by time of day Day of week and location so the code on a table always opens the menu that is being served
  • Per-table and per-location QR codes With printable sheets that survive a reprint
  • Diner-side filters that hide or highlight items by the recorded tags
  • Pages built image-light for a phone on poor signal
  • An analytics layer That shows views per item and per menu version. Where the venue wants it, the build adds order-to-table: a basket per table, an order sent to a kitchen ticket view with item status, a running tab, call-waiter and bill request buttons, and payment at the table through the provider the venue chooses

How discovery works

Discovery works through a service with you: which tables share a code and which need their own, how the menu changes across the day and between the bar, the terrace and the dining room, whether the kitchen wants tickets on a screen or printed, how a table's orders are grouped and settled, whether ordering is open to anyone who scans or gated behind a table code the waiter hands over, and what the venue counts as a menu that needs a new version rather than an edit. Each answer becomes a named workflow stage in the scope document.

  1. Scan
  2. Browse
  3. Order
  4. Kitchen ticket
  5. Served
  6. Bill request

Deliberately out of scope

  • The till itself, stock and recipe costing, and table bookings

When the scope grows

Scoping scenario

A food hall with eight independent kitchens wants one code per table that opens a combined menu, a basket that splits into a ticket per kitchen, a runner view that shows which kitchen has which table's items ready, one payment for the whole order and a settlement report per kitchen at the end of the day. That is a materially different build from a single-room restaurant that wants a fast, filterable menu without ordering, and the scope document says which one is being built.

Deliverables

What you receive

  • Discovery notes from a walk-through of a service across every area that has a code
  • A written scope document naming each stage from scan to bill request, with what is out of scope
  • Design of the diner menu, the manager editor and, where in scope, the kitchen ticket view, tested on a phone with throttled data
  • The build, deployed to your hosting or ours
  • Printable QR sheets per table and location, and migration of menus from your current files
  • Training for managers, waiting staff and the kitchen, with a one-page guide for menu versions
  • Handover material and full ownership of the source code and your data

Process

How a project runs

Each stage maps onto the project view in your client panel. Durations are set in your proposal, never on this page.

  1. Onboarding

    Access, contacts, your current menu files, table numbering and a look at any ordering app already in use.

    Project stage: Onboarding

  2. Planning

    Discovery with the operations manager, a head waiter and the kitchen; the scope document and milestone plan are agreed.

    Project stage: Planning

  3. Design

    Clickable designs of the diner menu and the editor, and the kitchen ticket view where ordering is in scope, checked on real tables with real signal.

    Project stage: Design

  4. Development

    Built in stages: menu model and versions first, then codes and filters, then ordering, tickets and payment where in scope.

    Project stage: Development

  5. Client review

    The venue runs a test service on a handful of tables alongside the old menu and tells us where versions, filters or tickets are wrong.

    Project stage: Client review

  6. Revisions

    Version rules, ticket grouping and diner layout are adjusted from the review and re-checked against the scope.

    Project stage: Revisions

  7. Ready for launch

    Menus loaded, codes printed and placed, kitchen screen installed, payment callbacks tested, checklist signed off.

    Project stage: Ready for launch

  8. Delivered

    The venue runs on the new menu and, where built, order-to-table; optional maintenance and hosting continue under their own agreement.

    Project stage: Delivered

Integrations

Commonly integrated

Systems this kind of business usually asks us to connect. Each integration is confirmed during discovery; none is assumed.

  • Card payment providers for pay-at-table and tabs
  • Till and EPOS systems so orders reach the existing point of sale
  • Kitchen printers or display screens for tickets
  • Property management systems in hotels for room charging
  • Translation services where a venue wants menus in more than one language
  • Analytics and reporting tools the venue already uses

How we would approach it

Worked example

Concept demo

A hotel with three service areas on one set of codes

The situation

A hotel with a dining room, a bar and a terrace wanted a single QR system where the code on each table knew where it was and what time it was.

Why it is a custom build

This needs a custom build rather than a generic QR menu because the menu is a function of table, location and time rather than a single document, and because room charging has to be checked against the hotel's own guest list rather than taken on trust.

The scope we would propose

  • Each table belongs to a location
  • Each location has a schedule of menu versions across the day
  • The terrace code opens the bar snacks menu until five and the dinner menu after
  • A room-charge option appears only for guests who enter their room number and surname
  • The kitchen ticket view groups orders by location so the terrace runner is not reading dining room tickets

Concept demo: a scoping scenario written to show how we would approach the work. It is not a delivered client project.

Pricing

What affects the price

Every proposal is priced on scope. These are the factors that move it most for this kind of build.

  • Number of venues, locations within them and tables that need their own code
  • How many menu versions exist across the day and the week
  • View-only menu or order-to-table with kitchen tickets
  • Payment at table, tabs and the payment provider involved
  • Connection to an existing till, printer or hotel property system
  • Menus in more than one language
  • Food-hall style split tickets and per-kitchen settlement
  • Hosting choice: your own hosting or ours

Start from a package

QR menu package

Per-table QR codes that open the right menu for the time and location, allergen filters, optional order-to-table with a kitchen ticket screen, call-waiter and bill request, and views-per-item analytics.

Custom build
View the package

FAQ

Frequently asked questions

Would the package do, or do we need a custom build?

A single venue with a handful of menu versions and optional ordering is usually covered by the QR menu package through configuration. A custom build is the honest answer for food halls with split tickets, hotels with room charging, or a till integration that has to be two-way. Discovery is where we tell you which.

Do we have to take orders through it?

No. Many venues want a fast, filterable menu that is always current and nothing more. Ordering, kitchen tickets and payment are scoped as a separate stage and can be added later without rebuilding the menu.

How do allergen filters work?

The kitchen records allergen and dietary tags against each item and diners can filter or highlight by those tags, with a prompt to tell staff about any allergy. The system publishes the venue's own records; keeping them accurate remains the venue's responsibility and no compliance claim is made by the software.

What happens if we reprint the codes?

Nothing breaks. Each code points at a table identifier rather than a menu, so the sheets can be reprinted, laminated or replaced and the menu behind them keeps changing as you edit it.

Who owns the system afterwards?

You do. Source code and your data, including order history and analytics, are handed over at delivery; hosting and maintenance are optional and separately agreed.

Get a project quote for qr menu software

Answer a few questions about your business, your current systems and what should change. We reply with a clear, competitive proposal.

Get a project quote Discuss a partnership
Get a project quote

Cookies on this site. Strictly necessary cookies keep the site working. Allow first-party analytics so we can see which pages lead to enquiries. No advertising, no third-party trackers, no personal data; you can change this at any time on the cookies page.

Manage preferences