Hospitality · App Starter
Restaurant Ordering Template
Your menu, your checkout, your kitchen screen — a complete ordering app generated into code the restaurant owns.
Delivery marketplaces take their cut of every order and keep the customer relationship as change. This starter generates ordering on your own domain: a menu that handles modifiers properly, a cart that gets the total right, and a kitchen queue that keeps tickets moving — all as code you can open and change.
- 6 core entities
- Kitchen queue included
- Code you own
- Vibe + Governed modes
01 · Data model
What's inside: the data model
Ordering breaks in the details — a burger with no onions and extra cheese is three tables talking to each other. Six entities model the menu, the modifications, and the order lifecycle, and every screen below reads from them.
| table | what it holds |
|---|---|
menu_categories | The sections of your menu — starters, mains, drinks — with display order and availability windows for lunch versus dinner. |
menu_items | Dishes with price, description, photo, dietary flags, and an availability toggle for 86'ing on the fly. |
modifiers | Options and add-ons — size, doneness, extras, removals — grouped per item with price deltas and required-choice rules. |
orders | A placed order with type (pickup, delivery, dine-in), status, timestamps, totals, and customer contact. |
order_items | The lines inside an order — item, quantity, chosen modifiers, and line price — exactly what the kitchen ticket prints. |
tables | Physical tables with QR slugs, so a scan opens the menu with the table attached and dine-in orders route themselves. |
02 · Screens
Signature modules
Public menu and cart
01A fast, phone-first menu grouped by category, with modifier pickers that enforce required choices before an item enters the cart. Prices, deltas, and totals compute from the same tables the admin edits — change a price once, and it's changed everywhere.
Kitchen order queue
02New orders land on a kitchen screen the moment they're placed, showing items, modifiers, and order type at ticket-reading distance. Staff advance tickets through preparing and ready with a tap, and the queue re-sorts by promised time, not arrival time.
Order status board
03Customers watch their order move from received to preparing to ready — on their phone for pickup, on a wall screen if you run counter service. Fewer "is it ready yet" interruptions is the quiet win of the whole system.
Daily sales view
04Revenue by day, top items, order-type split, and the hour-by-hour curve that tells you when the rush actually starts. It reads from live orders, so the number at close is the number — no export, no waiting for a platform report.
03 · Process
How it works
- 1You
Describe your restaurant
Menu structure, order types you take, whether tables get QR codes — plain language is enough. The starter brings the ordering machinery; your answers shape it.
- 2Vibe mode
Tune the flow in Vibe mode
Get the working app, then adjust it conversationally: add a modifier group, set lunch-only availability, change how the kitchen screen sorts. Every change is real code you can inspect.
- 3Governed mode
Go live through the governed pipeline
Deploy through approval gates onto your own infrastructure, with your menu and order history in your database — and no percentage of Friday night going to a platform.
04 · Fit
Who the Restaurant Ordering starter is for
Independents leaving marketplace commissions
When a marketplace takes 15–30% of every delivery order, the restaurant funds its own competition. Ordering on your own domain keeps the margin and — just as valuable — the customer's phone number, so the next order doesn't need the marketplace at all.
Cafes and counters moving to QR ordering
A QR code on the table that opens the menu with the table number attached removes the queue at the register. Orders arrive structured — no mishears, no handwriting — and the counter staff make drinks instead of taking dictation.
Ghost kitchens and food trucks
An operation without a storefront lives on direct orders. This starter is the storefront: menu, checkout, and status updates, running on a domain you control and costing what hosting costs — not a percentage of sales.
Small groups standardizing across locations
Two or three locations usually means two or three ordering setups. One codebase with per-location menus and kitchens gives the group one system to improve, and daily sales that compare like for like.
05 · Yours
Customize it, own it
Make it yours
Make the menu behave like your menu. Add availability windows so the breakfast category disappears at eleven, dietary and allergen flags that filter the public view, or a required doneness choice on every steak. Delivery zones, minimum order values, and pickup lead times are settings in your own code — set them to match how the kitchen actually runs.
Bigger moves are ordinary development on a normal codebase: wire in a payment provider for prepaid orders, add a printer bridge so tickets print in the kitchen, introduce a loyalty entity that counts visits toward a free item. There's no plugin marketplace and no per-feature tier — and no runtime dependency on Dual7 once you've shipped.
Why a starter, not a subscription
Restaurant tech has settled into rent-seeking: a monthly fee for the ordering page, a commission on the orders, and your own customer list held as a platform asset. Generating the ordering system as code inverts every one of those. The checkout is yours, the order history is a table in your database, and the regulars' contact details belong to the restaurant they're regulars of.
Owning it also means the system can be exactly as odd as your operation. The tasting-menu preorder, the half-tray catering size, the Tuesday special that auto-publishes — on a platform these are feature requests; in your codebase they're an afternoon. Dual7's governed pipeline keeps that freedom safe, with approvals and an audit trail between an idea and the live menu.
Restaurant Ordering template — frequently asked questions
What's included in the restaurant ordering template?
A full ordering stack generated into code you own: a public menu with categories and modifiers, cart and checkout, order tracking for customers, a live kitchen queue, QR-coded table support, and a daily sales view — six entities, deployed on your infrastructure.
Does it handle modifiers like extras and removals?
Yes, properly — modifier groups per item with price deltas, required choices, and free-text notes if you allow them. The kitchen ticket shows exactly what the customer picked, which is the difference between an ordering system and a complaints generator.
How do payments work?
The starter ships with the order flow ready for a payment integration — connect a payment provider for prepaid orders, or run pay-at-counter and pay-on-delivery without one. The checkout is your code, so the payment step matches your operation instead of dictating it.
Can customers order from the table with a QR code?
Each table has a QR slug that opens the menu with the table pre-attached, so dine-in orders arrive in the kitchen already knowing where to go. Print the codes once; the tables entity does the rest.
Can I 86 an item mid-service?
Flip the availability toggle on the item and it leaves the public menu immediately — no redeploy, no calling anyone. When the fryer comes back, flip it back. Sold-out handling is a column, not a support ticket.
Why not just stay on the delivery marketplaces?
Keep them for discovery if they bring you new customers — but move the repeat orders, where their commission hurts most, to a channel you own. Your regulars don't need a marketplace to find you; they need a link that works.
Related
Dual7 App Starters
Build your Restaurant Ordering on your terms
Your menu, your checkout, your kitchen screen — a complete ordering app generated into code the restaurant owns. Describe your version to start — the output is a project you own.