DEV3 Dishloft – QR Menu, Table Ordering and Kitchen Display SaaS Laravel Script with Split Bills, Waitlist, Waiter Calls

Dishloft is a QR menu and table-ordering platform that you run for restaurants, built by DEV3 Technologies on Laravel 12 and Filament 4. You are the operator: you sell plans to restaurants, and each restaurant gets venues, tables with printable QR cards, a photo-led guest menu, a kitchen display, a floor screen for servers and a host stand for the waitlist.

What it does

• Guests order from their phone. Scan the code on the table and a fast, mobile-first menu opens with sticky section tabs, search, dietary and allergen filters, option groups with minimum and maximum choices, and up to six typed-in languages (right-to-left included). Everyone at the table shares one cart, each line tagged with the phone that added it. If a dish was marked sold out or changed while it sat in the cart, the guest is told before sending.
• A kitchen display that fits a pass. Orders fan out into one ticket per station, with timers that turn amber at 80 percent of the target and red when late. Bump a dish or a whole ticket, recall the last ten, mark a dish sold out from the screen and print an 80 mm ticket from the browser.
• Floor, calls and host. A floor map with tables coloured by state, waiter calls (call, water, help, bill) with a live badge, a ready-to-run list, counter payments, comps and voids within each role's limit, and a host stand with a waitlist whose quoted wait comes from recent table turns, a table-ready text and reservation requests to confirm or decline.
• Split the bill and pay at the table. Request the bill, split it equally, by seat or by picking dishes, add a tip and pay each part on its own phone. The restaurant can also take payment at the counter. Receipts have their own link.
• Menu builder and manager panel. Menus with opening windows, sections, items with photos, allergens (14 flags) and diets, modifier groups, a translations grid, an allergen matrix, bulk sold out and bulk percentage changes, table cards as a printable PDF with rotatable QR secrets, stations, reports and a Pass Clock that shows every open ticket by age.
• Money you can reconcile. Guest payments go to your gateway as merchant of record. Each restaurant has a takings wallet that is paid out weekly after a hold, and failed refunds wait in a durable queue. A dishloft:check command proves orders, bills, payments and wallets agree.
• Operator panel and API. Restaurants with live meters, plans, subscriptions, platform invoices, table payments, payouts, pending refunds, an outbox, an audit log and audited view-only support sessions. A scoped REST API with an OpenAPI document and signed webhooks.

Quality checks

The release passed seven gates on the final code: Larastan level 6 with 0 errors, 242 Pest tests (2,133 assertions), a build well inside the page budget, migrations and the full demo seed on MySQL 8 and SQLite, a headless smoke test of 109 pages with 33 happy-path checks and 10 race groups on MySQL (two phones sending at once, three phones scanning one table, parallel payments of one bill, a bump racing a recall, a cancel or a void, two hosts seating one party and more), the installer driven from the zip, and a secret scan. The home page scores 98 for performance and 100 for accessibility on mobile.

What you should know before buying

• Guests order from their phone browser. There is no app to install, and there are no native apps for staff either: the kitchen display, floor and host screens are web pages for a tablet or phone.
• Payments are simulated by default. You are the merchant of record and pay each restaurant out from its takings wallet; restaurants cannot connect their own Stripe account in this version. A restaurant can also choose pay at the counter, which needs no gateway.
• Not a cash-till or stock system. It does not manage a cash drawer, stock levels or recipe costs, and it is not a delivery marketplace.
• Kitchen printers: use the kitchen display, or print the 80 mm ticket layout from a browser-connected printer. There is no ESC/POS driver.
• Reservations are a request form plus a waitlist, not a table-allocation engine: the host confirms or declines each request.
• Translations are typed in for up to six languages per venue; nothing is translated automatically. Allergen and diet flags are entered by the restaurant, which is responsible for their accuracy.
• Simulated drivers. Mail, SMS, payments and virus scan have working simulated drivers; real ones need your own accounts.
• A cron entry every minute and a queue worker are required. Live updates use Reverb, or fall back to polling every 10 seconds. Web only; Node.js is not needed (assets are prebuilt).

How it is different

Dishloft is the guest side of the table: scan, browse, order, kitchen, pay and split, plus a waitlist, with a multi-tenant operator layer on top. It suits an operator who wants to sell QR ordering to many restaurants rather than run one restaurant's own system.

Included

Source code, the web installer, a buyer guide with the API contract and a list of the race checks, demo data with fictional restaurants (a two-venue bistro group, a tapas restaurant with three languages, a ramen counter with two stations, a counter-only cafe and more) with six months of history and a live service in progress, a cron entry for the scheduler, and six months of support.