By industry
AI agents and automation for hospitality and restaurants
A restaurant has three versions of tonight: the one on the floor, the one in the kitchen, and the one in the books. We have built the operations system that keeps those in one picture — including the firmware on the devices it talks to — and we build the layer that answers guests, reconciles delivery platforms and keeps stock honest.
Two weeks to a written build plan · no obligation to build with us
- One state, in real time
- Floor to kitchenOne state, in real time
- We have built the device side too
- Custom firmwareWe have built the device side too
- Reconciled against your own orders
- AggregatorsReconciled against your own orders
- To a written build plan, via the audit
- 2 weeksTo a written build plan, via the audit
Where the time goes
If two of these are true, there is something here
Written the way the people doing the work describe it, not the way a process document does.
Three tablets on the pass, one per delivery platform
Each aggregator has its own device, its own menu and its own payout report. Orders are retyped into the POS, and the menus drift apart within a week.
Nobody knows what is 86’d until it is ordered
The kitchen runs out, the floor does not hear, the guest orders it, and the apology is the first anyone knows about it.
Reservations and walk-ins are managed by shouting
The book says one thing, the floor plan says another, and a table that has been empty for twenty minutes is still marked occupied.
Food cost is a monthly surprise
Purchases in one system, sales in another, waste in nobody’s. The variance appears at month end with no way to trace it back to a shift.
What we connect to
The systems you are already running
Hospitality stacks are POS-centred and everything else hangs off them. The hard part is usually the delivery platforms and the kitchen display, not the POS itself.
- POS and kitchen
- Toast
- Square
- Lightspeed
- Local POS systems
- Kitchen display systems
- Custom firmware
- Reservations and guests
- OpenTable
- SevenRooms
- Google Reserve
- WhatsApp Business API
- Phone / IVR handoff
- Delivery and back office
- Delivery aggregator APIs
- Inventory / recipe systems
- Supplier ordering
- Xero
- QuickBooks
What we build here
Five things worth building for hospitality & restaurants
Each one names the systems it touches, because an integration that is not named is an integration nobody has thought about yet.
- 01
One order stream from every channel
Dine-in, takeaway and every delivery platform normalised into a single stream against one menu, fired to the kitchen display in the right sequence, with the tablet farm on the pass retired.
- Touches
- POS · aggregator APIs · kitchen display
- What changes
- Orders stop being retyped, and the kitchen sees one queue.
- 02
Live availability across menus
When the kitchen 86s an item it disappears everywhere — POS, delivery platforms, online ordering — within seconds, and returns when it is back on. Menu changes are made once.
- Touches
- Kitchen display · POS menus · aggregator menu APIs
- What changes
- Guests stop ordering things that are not available.
- 03
Reservations and guest messaging
Bookings, changes, cancellations and waitlist handled in the guest’s own channel, checked against the real floor plan and covers limit, with confirmations and reminders that reduce no-shows.
- Touches
- Reservation system · floor plan · WhatsApp / SMS
- What changes
- The phone stops being the booking system and the floor plan stays truthful.
- 04
Aggregator payout reconciliation
Platform settlement reports matched against your own order records line by line, so missing orders, wrong commission and unexplained adjustments are found while a dispute is still possible.
- Touches
- Aggregator settlement files · POS sales · accounting
- What changes
- Platform deductions become a checkable number rather than an accepted one.
- 05
Stock, recipe and waste tracking
Theoretical usage from recipes and sales compared against actual purchases and counts, with variance broken down by item and shift, and supplier orders proposed from real movement.
- Touches
- Recipe data · POS sales · supplier ordering · counts
- What changes
- Food cost variance is traceable to a shift rather than discovered at month end.
How it is put together
How an order from any channel reaches the pass
Hospitality is unusual among the sectors on this site: the system is being read by people in a hurry, so latency and clarity matter more than sophistication.
- 01
Normalise
Every channel’s order becomes the same internal shape against one canonical menu, with modifiers, allergens and special instructions preserved exactly as the guest wrote them.
- 02
Check
Availability tested against current kitchen state — 86 list, prep capacity, station load — rather than against a menu that was correct at opening.
- 03
Sequence
Fire times worked out per station so a table’s courses land together. Delivery orders are sequenced against rider arrival rather than order time, which is where most cold food comes from.
- 04
Fail loudly
If an item cannot be made, the order stops in front of the floor manager with the guest, the channel and the item named. A silent failure in a restaurant is a complaint forty minutes later.
- 05
Record
Every order, modifier, void, comp and delay logged against shift and station — which is what later makes waste, prep and staffing analysis possible at all.
Your data
What we will and will not do with it
Stated plainly, and without claiming a certification we do not hold. If a requirement here is harder than what is written, say so on the call and we will tell you whether it is buildable.
Allergen information is never generated
Allergen and dietary data comes from your recipe records verbatim. Nothing is inferred, summarised or rephrased, and a guest question we cannot answer from the record goes to a person. This is the one place in hospitality where a plausible-sounding wrong answer is dangerous.
The kitchen is not an unattended write target
Orders fire automatically because that is the normal path. Voids, comps, refunds and menu price changes need a manager, because those are the actions with a cash impact and an obvious abuse route.
Guest contact data stays in your systems
Phone numbers and booking histories live in your reservation system, not in a vendor tool. Marketing use of them is your decision and your consent to collect, not something the system starts doing on its own.
Proof
We have built restaurant operations down to the firmware
Bguest needed the software and the hardware to agree. We built the operations system and the custom firmware for the devices it talks to, so orders, tables and kitchen state stay in one picture. Very few software companies in this category have written the device side as well as the app — which is the part that makes the floor-to-kitchen state actually real time.
- Written by us, not bought in
- FirmwareWritten by us, not bought in
- Floor-to-kitchen state
- Real timeFloor-to-kitchen state
Technology
What this gets built with
We pick the boring option unless there is a reason not to — the framework is the part most likely to be abandoned before your system is.
- Operations
- React
- Node.js
- WebSockets
- Offline-first clients
- PostgreSQL
- Devices
- Embedded C
- Custom firmware
- MQTT
- Kitchen display hardware
- Printer protocols
- Integration
- POS APIs
- Aggregator APIs
- Reservation platforms
- WhatsApp Business API
- Back office
- Recipe costing
- Settlement reconciliation
- Xero / QuickBooks
- Shift reporting
How the engagement runs
Five phases, each with something you can hold
Every phase ends in a named deliverable. You can stop after any of them and keep what has been built.
- 01Week 1–2
Sit with the work
We watch the process as it is actually done, not as the process document says. The output is a map of every step, which system it touches and how long it takes.
DeliverableProcess map and a shortlist of what is worth automating - 02Week 2–3
Design the access layer
Which systems get read, which get written to, what scope each credential carries, and which decisions stop for a person. Agreed in writing before anything is built.
DeliverableArchitecture and permission model - 03Week 3–8
Build against your real data
Built in your sandbox against real records, not a demo dataset. The write path goes through a review queue from the first day, so nothing lands in a live system unseen.
DeliverableRunning system in staging, with the review queue - 04Week 8–10
Run it beside the humans
It runs in parallel with the people doing the job. We compare the two outputs, fix what differs, and only then start letting the routine path through unattended.
DeliverableAgreement rate report and a go-live threshold - 05Ongoing
Hand over and watch
Source code in your repository, deployment in your accounts, cost and failure dashboards you can read without us. Support if you want it, not because you are locked in.
DeliverableRepository, runbook and monitoring
Why Devs Core
Three reasons that are checkable
We run two of our own products
Cadenza and Budge are ours. What an agent costs per run, where it fails and which decisions need a person came from operating them, not from a vendor deck.
The write path is reviewed by default
Anything that changes a record in a system of record goes through a queue a person can see. You choose what graduates to unattended, and when.
You own the code
Source in your repository, infrastructure in your accounts, model keys in your name. There is no runtime of ours you have to keep paying for.
Questions
Hospitality & Restaurants — the questions we get asked
Do we have to replace our POS?
No, if it has an API or an export we can work with. The POS is usually the one system in a restaurant that works; the problems are around it — the aggregators, the kitchen display, the menus and the reconciliation.
Can you connect to the delivery platforms directly?
Where they offer partner APIs, yes, and that is the right way. Where they do not, integration is limited to their settlement exports and the tablet stays. We will tell you which case you are in before you commit to a build, because it changes the value of the project substantially.
Can an AI take phone bookings?
We do not build voice agents — we would be claiming a capability we have not shipped. Text channels, WhatsApp and web booking we do build, and in most markets those already carry the majority of bookings.
What happens if the internet drops mid-service?
The floor and kitchen clients are built offline-first and keep working against local state, syncing when the connection returns. A restaurant system that stops when the router does is not a restaurant system, and this is the part of the Bguest work that taught us most.
Can it answer guest questions about allergens?
It can read out exactly what your recipe records say, with no rewording. If the record is incomplete, it says so and gets a person. We will not generate allergen text, and we would advise against any system that does.
We are a small group of two or three sites. Is this over-engineered?
The order-stream and menu-availability piece scales down well and usually pays for itself at two sites. The stock and recipe variance work needs enough volume for the numbers to mean something, and we would rather sequence it second than sell it first.
Related
What hospitality & restaurants buys most often
- Read more
Custom Software Development
The operational system underneath — the one the packaged software did not cover. React and Django, built to be handed over.
From $14,000 - Read more
AI Integration Services
The access layer between the software you already run and any AI model — so an agent can reach your ERP, CRM or helpdesk without being handed the keys.
From $8,000 - Read more
Process Automation
Replace the manual steps between two systems — the re-keying, the copy-paste, the spreadsheet that reconciles what neither system knows.
From $4,500 - Read more
Mobile App Development
iOS and Android from one Flutter codebase, or native where the hardware demands it.
From $9,000
Tell us which process is costing you.
Thirty minutes, no preparation, no deck. You describe what keeps going wrong and we tell you whether AI is the answer — including when it is not.
Prefer email? contact@devs-core.com