Case study: a custom ERP for a five-venue hospitality group, in 16 weeks

01 · The client

A family-owned hospitality group on the Greek coast: five venues, built up one at a time over fifteen years. A seafood bistro by the marina, a pier restaurant, a taverna, a bar-restaurant, and a coffee shop. Venue names in our public demo are placeholders — the client asked to stay unnamed, and we respect that. Everything else in this case study is the real project.

Each venue had been opened at a different time, by a different combination of family members, and each had inherited its own way of doing things. That is normal. It is also, past a certain size, expensive.

02 · What they were running before

When we sat down for the first conversation, the group was operating on:

• Three different cloud POS systems across the five venues — two venues shared one vendor, the rest had picked their own
• Inventory in Excel, one file per kitchen, maintained by whoever closed that night
• Supplier orders over phone calls and WhatsApp photos of handwritten lists
• A consolidated P&L from the accountant, arriving roughly three weeks after month-end
• No single screen, anywhere, that showed how the group was doing today

The monthly software bill across POS subscriptions, a scheduling tool, and assorted add-ons came to more than most people would guess — but the real cost was not the subscriptions. It was the owner driving between venues every evening to ask the same three questions, and stock running out mid-service because nobody saw it coming.

The real cost was not the subscriptions. It was the owner driving between venues every evening to ask the same three questions.

03 · The scope — one page, sixteen weeks

After four discovery conversations we put a one-page plan on the table: a single web application covering POS, inventory, and business intelligence for all five venues. On-prem, on a server in the group's own back office — the owner was explicit that fifteen years of sales data was not going to live on someone else's cloud.

Sixteen weeks, fixed line-item quote, weekly working software in the client's hands from week five onwards. No status reports, no slide decks.

04 · Weeks 1–4: we worked the floor

Before writing code we spent time in all five venues during actual service — watching orders move from table to kitchen, watching the closing count, watching how the morning supplier delivery actually gets checked in (quickly, and from memory).

Three findings shaped the whole build:

• Every venue had a different ordering ritual, and each one existed for a reason. The system had to absorb the differences, not flatten them.
• Stock problems were always discovered at the worst possible moment — mid-service, when the dish is already ordered. Urgency had to be visible before service, not during.
• Senior staff trusted paper because paper had never crashed on them. Whatever we shipped had to be faster than the notepad, or it would lose.

05 · Weeks 5–16: build in the open

POS came first — piloted in the coffee shop, the smallest and most forgiving venue, then rolled out venue by venue. Inventory came second, with one rule we refused to compromise on: any item projected to run out inside its reorder window gets flagged urgent, visibly, on the dashboard everyone sees — not buried in a report.

BI came last, deliberately. By the time we built the dashboards, the system had weeks of real transactions in it, so every chart was designed against real data — live revenue per venue against its own average, covers, average ticket, margin — rather than against our assumptions.

06 · What the owner sees now

Every morning, one screen: yesterday's revenue per venue against its average, today's covers as they happen, average ticket, group margin, and the urgent-stock list — every item across five kitchens that will run out before the next delivery if nobody acts.

The evening drive between venues still happens. But now it is for the reasons an owner should visit — not to collect numbers.

The evening drive between venues still happens. But now it is for the reasons an owner should visit — not to collect numbers.

07 · Results after the first full season

• Reporting lag went from roughly three weeks to live — the consolidated picture exists at all times, not at month-end
• Seven subscriptions and tools consolidated into one system, with one login per employee
• Mid-service stock-outs on flagged items dropped to near zero within the first two months
• Supplier orders are generated from actual stock levels instead of memory and WhatsApp
• The group owns the system, the server, and every row of its own data

We will publish harder financial numbers when a full year has passed — a season is enough to see operational change, but we do not believe in projecting annual ROI from a summer.

08 · What we would do differently

Honesty section, because that is the point of these case studies. Two things:

We underestimated training time for senior staff. The interface was fast, but fifteen years of muscle memory is faster, and we should have budgeted for shoulder-to-shoulder time during live service from the start instead of adding it mid-rollout.

We built the bilingual interface as English-first with a Greek toggle. In hindsight, for a Greek kitchen and a Greek floor team, it should have been Greek-first from day one. It was a quick fix — but it was our assumption, and it was wrong.

09 · See it yourself

There is a live, interactive demo of this system at https://www.oryaone.com/erp-demo — the dashboard, the venue view, inventory with the urgent-flag logic, and the POS order screen. The data in the demo is placeholder; the workflow is the real one.

If your business runs on three POS systems, a folder of spreadsheets, and an owner who collects numbers by car — this is the kind of project we scope in four conversations. The first one costs nothing.

• case study
• ERP
• hospitality
• on-prem