An operations analytics platform for a two-site restaurant group, built in-house by the operator.

The problem

Bar Azita runs on four systems. Blinq handles point of sale, Planday handles scheduling and labour, SevenRooms handles reservations, Xero handles the P&L. Each one is good at its own job. None of them talk to each other.

That gap is where the actual operational questions live. Was Tuesday overstaffed? What does a wet Saturday do to covers on the horsebox? Is the labour percentage at 7pm the same story as the labour percentage for the week? Answering any of those meant pulling exports from three places, reconciling them against cashup sheets by hand, and arriving at a number that was already several days old.

The weekly reporting was a spreadsheet assembled manually. It told you what had happened. It could not tell you what was about to.

Why build rather than buy

The obvious first move was to look for a product that already did this. Nothing covered all four sources cleanly. The tools that came closest either assumed a single-site operation, required replacing systems that were working fine, or offered dashboards that could not be reshaped as the business changed. A two-restaurant group with a seasonal horsebox bar is an awkward size: too complex for the simple tools, too small to be worth a vendor's integration effort.

So the decision was to build a reporting layer on top of the systems already in place, rather than migrate away from them.

Getting the data out

The unglamorous part, and the part that took longest.

SevenRooms was the hardest. API access was not included in the existing contract. It came out of a renewal negotiation in mid-2026, where the requirement was raised explicitly and not a third-party integration, but direct API access for an internal reporting dashboard.

Planday authenticates over OAuth2 with a refresh-token grant. The useful endpoints are employees, departments and shifts. The portals endpoint returns nothing and is a dead end.

Blinq exports transaction CSVs in UTF-16, tab-delimited. The column to use is net item sales, excluding VAT and service charge — not the headline item sales figure, which quietly inflates everything downstream if you grab the wrong one.

Historical cashups live in Google Drive and are read through a service account.

Weather comes from Open-Meteo, both historical and forecast.

Architecture

A Node and Express backend holds every credential and acts as the only thing that talks to the outside world. The browser calls the backend's own routes and receives clean JSON; it never sees an API key. Charting is Chart.js. The whole thing runs on Railway.

That design was not planned as a security architecture so much as arrived at, but it turned out to matter. When a separate project later needed a public booking endpoint on the website, the credential-holding proxy already existed — the hard part was done, and the only question was how to expose one deliberately public route without leaking the private operational data sitting next to it.

What it does

Year-on-year P&L comparison by site

Live labour cost percentage, by site and by hour

Sales per labour hour

Staffing against revenue pattern analysis, surfacing the over- and understaffed hours

Capacity utilisation heatmaps — hourly revenue across the days of the week

Demand and booking forecasting, with no-show rate tracking

Booking window analysis

A weather-calibrated cover prediction model for the horsebox bar

A weekly profitability and efficiency summary

The forecasting engine

The naive approach is per-person-cover: take an average spend per cover, multiply by forecast covers, call it revenue. It is simple and it is wrong, because spend per cover is not constant. A quiet Tuesday and a full Saturday behave differently, and not in a way a single multiplier captures.

What works better is grouping historical days into cover-count bands and learning a lookup table for each. The model then asks what days that looked like this one actually did, rather than applying one blunt ratio across every trading pattern.

On top of that sits contextual weighting for the things that genuinely move a Hertfordshire restaurant: local school holidays, UK bank holidays, payday weekends — the last Friday and Saturday of the month — weather, and recency, with the most recent four weeks weighted four times.

An outlier filter strips days where spend per cover exceeds three times the median, because those are almost always data artefacts rather than real trading.

Real-world data is hostile

Three examples, all of which cost time.

The Hitchin column shift. Hitchin cashup sheets sometimes carry an extra column for the horsebox card machine, which moves everything after it. Reading by fixed column position works until the week it silently doesn't. The fix is dynamic header detection: scan for the label, find the column, never assume position.

The May anomaly. One day showed a wildly implausible spend per cover against a low cover count. The cause was a reservation platform switch that happened mid-service, leaving that day's booking data incomplete on both sides. Worth recording not as a bug but as a known pattern: any platform transition produces a data scar, and reporting needs to either exclude or annotate it rather than average it in.

The wrong sales column. Using gross item sales rather than net puts VAT and service charge into every margin calculation downstream. Easy to do, and the resulting numbers look plausible enough that nothing obviously breaks.

Things that broke, and what they left behind

Route ordering. The forecasting endpoints were registered after a catch-all proxy route, so every forecasting request was silently forwarded to Planday instead. Nothing errored. It simply returned the wrong thing. Specific routes now always go before wildcards.

A const that needed to be a let. A variable reassigned during outlier filtering, failing silently at runtime.

Inline scripts running before the canvas existed. Content injected via innerHTML executes immediately, before the elements it needs are in the DOM. Chart data now travels as data attributes and draw calls are deferred to the next animation frame.

None of these were interesting problems. All of them were expensive. What they produced is a deployment habit: syntax-check before deploy, grep for duplicate function definitions to catch stale code, and keep a tagged known-good baseline to roll back to.

Where AI fits, and where it doesn't

AI was the build tool throughout - integrations, parsers, chart code, documentation. It made a project like this possible alongside a full-time operational role, which it would not otherwise have been.

The working rule is that output is a draft, never a result. Everything gets validated before it gets deployed. The route-ordering bug is the standing example of why: the code was syntactically perfect, ran without error, and was completely wrong. No amount of confident-sounding explanation substitutes for checking what the endpoint actually returns.

And there are places it does not go. Credentials and API calls stay server-side, never in the browser. Anything touching payroll or customer data gets verified against source before it informs a decision.

What it changed

Before the data was there but the ability to piece it together was not. We were acting so retrospectivly to information that it was hardly useful. This allowed us to pull in infomation in real time and use it to shape our decisions. We can now acurately retrieve metrics without spending hours crunching spreadsheets.

What I'd do differently

Build the data-quality layer first. Most of the lost time went on parsers that assumed clean, consistent exports and broke on the first real week of data. Dynamic detection and outlier handling were retrofitted when they should have been the foundation.

I would also separate the public and private surfaces from the start, rather than discovering the distinction when a public-facing feature needed the same backend.

Why this matters beyond one restaurant group

Groundwork is a small system. What it represents is the position most multi-site hospitality operators are in: several good tools, no connective tissue, and a weekly reporting process held together by manual work that nobody has time for.

I built it because I was the customer and nobody was going to build it for me. That experience and being on the receiving end of implementations, integrations and data migrations, is the part I would bring to the other side of the table.