Home  /  Case studies  /  Food & hospitality
Food & Hospitality

The technology partner for a food group with 14 venues.

Three brands, fourteen venues, six hundred staff, no shared system of record. The central team was losing their evenings to spreadsheets. We rebuilt the spine of the business around Supabase and a lightweight internal app — and signed on as their ongoing tech partner.

Built with
Supabase
Next.js
Xero
Twilio
n8n

The brief

An independent food group, growing fast. Three brands — a casual chain, a fine-dining group, and a delivery-only kitchen — under one operating company. They didn't need an ERP, they needed an answer to a single question repeated about forty times a week: "why don't our systems agree?"

The ops director, who'd done a remarkable job holding everything together with spreadsheets and willpower, called us after the third consecutive Sunday spent reconciling supplier invoices against a stock-take.

What was actually broken

Nothing was broken. That was the problem. Every individual system worked. They just didn't talk:

  • EPOS in each venue, but three different brands of EPOS across the group.
  • A rota tool that knew who was working but not what they cost.
  • A stock system that knew what came in but not what was sold.
  • Xero at the centre, lagging two weeks behind reality.
  • An allergen spreadsheet per venue, maintained whenever the head chef remembered.
  • Recipes in a shared Google Drive that was last reorganised in 2022.

The central team's job had quietly become to be the integration layer. Manually. In Excel. On Sundays.

"We weren't running a food group. We were running a copy-paste operation that happened to serve food." — Ops director, kickoff

The shape of the system

We resisted the obvious move — replace everything with one big platform. The team didn't have the appetite or the budget for it, and we didn't think it was the right answer. Instead, we built the layer in the middle they'd been doing by hand.

  • A single Supabase warehouse as the system of record. One canonical model for items, recipes, venues, staff, suppliers, allergens, and cost centres.
  • Connectors pulling from each EPOS, the rota tool, the stock system, Xero, and the bank feed — on schedules ranging from real-time to nightly, depending on what the data was for.
  • A lightweight internal web app, deployed to Vercel, where the central team and head chefs actually live during the working week. Stock-takes, recipe edits, allergen sheets, supplier invoicing, daily covers — all in one place, with the warehouse behind it.
  • A SMS layer over Twilio for the people who don't sit at a desk. Stock counts come in by SMS in some venues, structured by a small parser. Shift confirmations go out the same way.
  • A weekly P&L per venue, generated automatically every Tuesday morning, accurate to the previous Sunday.

The thing we got wrong, first

We launched the first version of the recipe-costing module and the head chefs hated it. Not because it was broken — because they hadn't asked for it, and the form had eleven fields when seven would do. We rewrote it in two days with a chef sitting next to us, and the rewrite is what shipped.

This is a lesson we keep relearning. Operations software for people who do physical work has to be designed by sitting in the kitchen, not by reading a spec.

The outcome

14
Venues on a single source of truth.
−2.4%
Food cost as % of revenue, post-launch quarter.
2 days
From month-end to a signed-off P&L (was ~3 weeks).

The food-cost drop alone covered our fees several times over inside the first quarter. The deeper outcome is harder to put a number on: the central team is no longer the bottleneck. New venues plug into the same backbone in days, not months. Allergen sheets are correct, current, and printable. Head chefs can see their own margins on Monday morning. The ops director is back to her evenings.

We're now on retainer as the food group's ongoing technology partner. New venues, new brands, new compliance requirements — they call us, we ship.

What we learned

The right answer is rarely a platform.

Buying a single ERP would have cost more, taken longer, and ripped out tools the staff actually liked. The cheaper, faster, more durable answer was a shared data layer behind the tools they already used.

Operational software needs operational people in the room.

We made our biggest mistake of the project the one time we tried to build something without a chef present. We'll keep not doing that.

SMS isn't legacy. It's resilient.

Half of the people whose work touched this system don't use a laptop in their job. SMS is a perfectly good user interface, when the data behind it is clean. It also keeps working when the WiFi doesn't.

The one thing to take away

If your business runs on spreadsheets that someone reconciles on a Sunday, you don't have a tools problem — you have a data-layer problem. The fix is almost never an ERP. It's a quiet, well-modelled warehouse and a UI that respects how the work actually gets done.

Free tool

Not sure if this is the right service? Try the audit first.

A 5-minute interactive audit gives you a score and three pattern-matched recommendations. No commitment.

Take the audit → 5 minutes · free · no signup
Talk to us

Got something like this?

Two paths in: drop us a line, or book a delivery call if you already know what you want shipped. Both land in the same inbox.

Email
hello@intellilabs.studio
Hours
Mon-Fri, 09:00-18:00 UK
Reply
Within one working day

Drop us a line.

We'll get back within one working day, usually faster.

By submitting, you agree to us getting back about this enquiry. No newsletter.