Writing

Food halls, festivals, and the bits nobody demos.

Written from inside a working food hall. Problems we have hit, arithmetic we got wrong the first time, and the questions worth asking any supplier — including us.


Deleting a dish that is on last month's orders

Archive, never delete, is easy to say and easy to write down. Our own Delete on a recipe ran one unconditional statement, and a dish sold a thousand times could have been destroyed by the vendor who sold it.

Read it →

A report with nowhere to appear

A weekly job, a database table, an endpoint that answers correctly, and no screen anywhere. From either end it looks finished — only the missing caller says otherwise.

Read it →

Seven doors and two handles

A staff availability feature with seven endpoints on the server and two of them reachable from the app. Half-built features do not announce themselves; they look exactly like finished ones from the outside.

Read it →

A check that could not see the question

We built a check to find endpoints nothing calls. It named four that are called constantly — because it could not see four of the five ways our own pages ask for things.

Read it →

What a support account should never see

Ten families of endpoint, all of them a venue's money, sat outside the list that is supposed to keep support staff away from financials. Hiding the menu item is not the same as closing the door.

Read it →

A guard that only checked the first door

Our menu reader refuses to fetch private addresses. It checked the address you pasted and nothing after it — so a public link that redirected somewhere else walked straight past the check.

Read it →

The commonest sale was the one that would have failed

Card payments on a tab carried a reference. Ordinary counter sales carried none — and the card company requires one. The rare path worked; the frequent one would have been refused on the first press.

Read it →

A test that reads the code but never runs it

Two tests covered our card adapter. Both were searches over its source — they asserted what it must not contain and never made it do anything. A green suite, and a bug on the second real test.

Read it →

An error log nothing was ever written to

Our card routes logged every provider failure to a table that does not exist. The write was wrapped in a catch, as it has to be, so it failed silently — and the errors screen showed nothing, which reads exactly like nothing going wrong.

Read it →

One card key for ten kitchens is one bank account for ten businesses

Our first card-reader integration used a single platform-wide key, the way we hold a key for sending email. For money that is wrong: every venue would have charged into the same merchant account.

Read it →

The number the chef acts on was the smallest thing on the screen

A kitchen display showed the quoted wait in 34px and the number of tickets still to make in 13px grey — and dropped it altogether on a narrow phone. What a kitchen screen should put first.

Read it →

Popular is not a pairing

If a drink is in a third of all baskets it will be the top "goes well with" for every dish on your menu. That is not a pairing — it is a restatement of the bestseller list. What to measure instead.

Read it →

A report that will not tell you it made you money

Upsell reports love the phrase "extra revenue generated". Almost none of them can know that. What an honest suggestion report can claim, and the sentence ours refuses to write.

Read it →

A row that could only ever say zero

A report we shipped had a line for the kiosk that was structurally incapable of showing anything but nought. The fault was mixing two different questions into one list — and it is a common one.

Read it →

A setting that only half the screens obeyed

We added a switch to turn the add-on row off. It turned it off on the guest menu and left the register still offering them — because two screens read the same setting from two different places.

Read it →

The photo was fine. The label was not.

A manager photographs a contract, uploads it, and the system refuses it — because a browser guessed the file type from its name and guessed wrong. Why an upload should read the file rather than believe its label.

Read it →

An error message with a request id in it

A manager uploading a contract was shown a raw 400 from an API, JSON and all. It read as a broken product. It was a file that needed swapping — and the difference is entirely in who the message was written for.

Read it →

A long list should load before you get to the bottom, not when you arrive

Our product list stopped at 100 of 131 items, and the fix taught us two things about loading long lists that are easy to get almost right — and one of them looked correct in every test we had.

Read it →

A default that never applied, and the dish that would not save

Adding a new dish failed with a NOT NULL constraint error printed on screen. The column had a default. Defaults do not work the way most people assume, and a second bug report turned out to be the same one from the other end.

Read it →

An empty list proves nothing

We checked whether the past-orders screen scrolls properly. It did — on a venue with no orders. That is not a test, and the same mistake is the most common way a system passes its own checks and fails on a Saturday.

Read it →

A kitchen called Loco Lime is called Loco Lime in every language

We put the whole product into 26 languages and immediately had to answer a harder question: which words are language, and which are somebody’s name? Get it wrong and a guest orders a Beef Taco from a menu that says Taco de Birria.

Read it →

Zero errors, and the job had failed: reading what a report actually says

A bulk job finished cleanly. Every line said "0 errors". Every line also said between 54 and 657 items missing, and that second number was the bug report nobody had read. What we found underneath, and why it happened twice.

Read it →

We measured ten screens and believed it about a hundred and five

A check said our system was sending none of our customers’ data to a translator. It was true of the ten screens we checked. Across all 105 it was nine per cent — and the screens we missed were the ones that print the whole product list.

Read it →

Every page, in 26 languages, without the wait

Switching language used to mean waiting while a machine translated the screen in front of you. We translated the whole product up front instead — 2,080 phrases into 26 languages — so the switch is now a lookup. What that costs and why it is done once for everybody.

Read it →

One hall, ten kitchens, one way of showing them

A food hall’s QR landing page is a grid of its kitchens, and the grid is the hall’s shopfront rather than each vendor’s. Three card formats, chosen once by the hall, applied to every kitchen — including the ones that have not uploaded a photo.

Read it →

Eleven seconds to under three: the register got its own page

A phone opened our register cold and waited 11.8 seconds — for a back office it would never use. The till now has its own page, a third the size, and the first real phone measured 2.8 seconds cold and 15 milliseconds for the screen after. Why the board now separates the two.

Read it →

Move it on screen first, save it after

Dragging a dish up the menu did nothing you could see, then redrew the whole page a second later — and a second drag during that second confused it. Three complaints, one cause: every move waited for the server. The row now moves the instant you drop it, and the resulting order is what gets saved.

Read it →

A tick box that hid your dish from everyone

At the far left of every row on the menu screen sat a tick box with no label. Unticking it removed the dish from the guest menu, the kiosks and the till. Somebody who found that out by pressing it called it crazy — and asked for an eye. What a control owes the person about to press it.

Read it →

A setting that is off by default is not a fact

Our own pages said staff clock in "with a photo on every punch" — a photo that is optional, off until a venue switches it on. Eleven sentences promised something most venues would never see. How we found them all, why a source search found only seven, and the rule that now reads the rendered pages.

Read it →

Raw bytes are not the wire

The menu the till downloads was 177 KB, and 91 KB of it was the same eight modifier groups repeated under 39 dishes. We sent each group once and the file shrank by 70 KB. Then we measured what actually crossed the wire: 17 KB before, 16 after. What the change really bought, and the measuring mistake it exposed.

Read it →

A board that lists every page, slowest first

We now time every page of the product in the browser that loaded it — the till, the kitchen screen, the guest menu, the public site — and the owner sees them ranked slowest first against a 300 ms budget. What that took, and what the first day of real numbers said.

Read it →

A year in the cache, for a file whose address changes when it does

Every script and stylesheet we ship carries its version in its address, so a browser could keep it for a year. Ours were told to re-check every one on every page — 138 questions per screen with the same answer. One file fixed it, and it created a rule we now cannot break.

Read it →

The stylesheet that now arrives with the page

A first visit to any page paid a second round trip before it could paint: the stylesheet. On a phone that was half the wait. It now travels inside the page, lightly minified, and a careful check that the minifier changed nothing — including the false alarm the check raised first.

Read it →

A crawler is not a customer

The first day of our load-time board filled with nine marketing pages at one visit each, all around a second, hours apart. Nobody reads a site like that. A search engine rendering it does, and its numbers would have set every page’s average. How we tell them apart, and the trap our own tests fell into.

Read it →

A tab opened in the background is not a slow page

The worst row on our load-time board said the home page took 7.4 seconds — on a page that paints in under half a second. The browser had deferred the paint because the tab was behind another one. Why a field measurement has to know when the page was hidden, and the one-line rule that keeps the board honest.

Read it →

The sales report that said £0 to a kitchen that had taken £800

A sales report can be built from the wrong table and look fine for months. Ours priced the stock that left the shelf at the ingredient’s selling price — which is zero, because nobody sells a tortilla. What it should have read, and what “sales” has to mean.

Read it →

A tip is not turnover: how a venue chooses to ask for one

Tips at a QR checkout: fixed amounts, percentages, or amounts on small bills and percentages on big ones. What a venue may set, what it may not — nothing pre-selected, the food as the base — and where a tip goes in the numbers afterwards.

Read it →

The venue table that cannot take one more column

A per-venue setting is the most natural thing to add as a column on the venues table — until the table hits the database’s limit and the change can never be applied. What we found at exactly one hundred, and the pattern that replaces it.

Read it →

Nine round trips in series: why one screen on the till was slow

The Money tab on the register asked the database nine questions one after another, when it could have asked most of them at once. How we found it from the till’s own timing, what changed, and why the phone’s network still gets the last word.

Read it →

The manager who runs the kitchen could not save its settings

Roles in a food hall till: owner, kitchen owner, manager, counter. A kitchen manager could see every venue setting and change none — every save came back refused. Which settings a manager should hold, which stay the owner’s, and why.

Read it →

When the crash report says nothing was thrown

Some errors arrive with no message and no stack — a promise that failed with nothing to show for it. You can still catch them. A short trail of what the screen just did turns "something broke" into the step that broke.

Read it →

A festival till and a food-hall till are sold as different things

Every POS company splits its site by venue — festivals here, food halls there, stadiums over there. Underneath it is the same three problems, which is why one system can serve all of them without pretending to be several.

Read it →

Some settings belong to the vendor, some to the hall

A kitchen can decide how its own receipts read. It cannot decide whether it charges the hall card fee. A settings system for a shared site has to know the difference — and let the owner lock the ones that are the hall's to set.

Read it →

A till screen you never have to scroll

At a busy counter a scrollbar is a lost second and sometimes a wrong tap. The register is built so everything fits one screen at any size — by scaling the whole layout to the glass, not by hiding half of it below the fold.

Read it →

Why your till should count in pennies, never pounds

Store £4.50 as a decimal and sooner or later a rounding error turns a five-kitchen split into a total that is a penny out. Every figure here is whole pennies until the instant it is shown. That is not fussiness — it is how the split adds up.

Read it →

Sending a meal out in courses, without a fine-dining till

A sit-down table wants starters, then mains, then pudding. A street-food bag goes out all at once. A till should ask which course a dish is for only when it matters — and the kitchen should see the ticket banded the same way.

Read it →

The best new till is the one your staff have already used

Casual hospitality staff turn over fast and arrive knowing a Square or a Lightspeed. A register that copies the layout they already have in their hands is a register nobody has to train — so it copies the good ones on purpose.

Read it →

Holiday that follows the contract, not a number in a box

A kitchen porter on twenty hours and a supervisor on a salary do not build up holiday the same way. When the contract changes, the entitlement should change with it — worked out from the terms in force, not typed in once and forgotten.

Read it →

The rota in the language your kitchen actually reads

A food hall’s staff rarely all share one first language. The apps they clock in and read their shifts on can switch the moment they choose one — here is how a screen translates itself, and the one honest catch on the first visit.

Read it →

When something breaks mid-service, the till should say what

A bare “500” tells the person running the floor nothing. A useful error log names the screen it happened on, counts how often, and puts the worst first — so the owner can act on it instead of waiting for a customer to report it.

Read it →

What a food hall till has to hide from the stall next door

In a food hall, several separate businesses share one system. A trader must never see the kitchen next door’s takings, staff pay or supplier prices. Here is what that isolation has to cover, and the quiet way it leaks.

Read it →

Cash up should read every order, not the last few hundred

A cash-up screen that works its expected drawer from a capped list of orders quietly understates what should be there — and writes the wrong figure into the record as proof nothing went missing. Why the count has to read the whole period.

Read it →

A report that sorts worst-first can hide your worst kitchen

A report capped at the newest few hundred rows, sorted worst-first, will drop the exact row you opened it to find. A short tour of how a cap on a summary lies, and why it gets quieter as you grow.

Read it →

Moving stock between two kitchens, and who signs for it

When one kitchen in a hall lends stock to another, one number update is not enough. A transfer is three moments — sent, in transit, received — and the person who sent it must not be the one who signs it in. Why the van in the middle matters.

Read it →

Putting a buzzer number on the ticket, and calling it back

A collection order needs a handle the counter and the customer both hold. A buzzer number on the kitchen ticket and on the ready screen is that handle — as long as it is written where the person plating can see it without hunting.

Read it →

Your till thinks the day ends at 1am

From late March to late October, British clocks are an hour ahead of the clock most software counts in. If your POS works out "today" the easy way, the drawer figure it shows you is wrong twice a day — once by an hour of takings, and once by a whole day of them.

Read it →

A drawer that balances and is still short

Your cash-up screen says the till took £685 and there is £685 in the drawer. It took £849. Nothing on the screen is red, the count gets signed off, and the shortfall is now filed as proof that nothing went missing.

Read it →

The worst counter was not on the list

A hall owner asks one question of guest feedback: which kitchen are people unhappy with? Our report answered it from the newest 500 answers, so the one kitchen everybody complained about was missing from the list entirely.

Read it →

Paying a kitchen twice for the same week

A payout screen works out which days nobody has been paid for yet. Show it only the most recent runs and the ones it cannot see stop counting as payment — so a year that was settled comes back as a gap, priced, on the bill.

Read it →

A percentage that quietly exonerates

On a report built to catch till fraud, every rate had a capped top and an uncapped bottom. It made everybody look better than they were, and it truncated the small, frequent discounts first — which is what the pattern actually looks like.

Read it →

Ask your reports how many rows they read

Four wrong numbers in four days, all one cause: a limit meant for a list, quietly reused for a total. Here is the shape, why it hides so well in hospitality software, and the questions that flush it out of any system.

Read it →

An item with no price is not a menu item

We found a live QR menu offering customers toilet roll, bin bags and cling film, all at nothing. Two ordinary settings met and produced something nobody would ever have typed on purpose.

Read it →

Who tells the kitchen its allergens are blank?

Our guest pages have always been honest about a dish with no allergen answer. What nobody had built was the other half: telling the operator, on the screen where they actually work.

Read it →

A stock photo under a brand name is a lie

Finding a decent photograph of "beef burger" is easy and fair. Finding one for Diet Coke, or a named champagne, is neither — so the honest answer is to refuse.

Read it →

Ten kitchens, one photograph

The tenth kitchen in a hall selling fries should not pay to look up a picture of fries. Keyed properly, a photo library gets cheaper for everyone the more people use it.

Read it →

When two numbers on one screen disagree

A dashboard that says six items are live while the customer menu shows five is worse than one that says nothing. We have now caught this three releases running, always the same cause.

Read it →

An open tab should shout its age

A competitor's till showed twenty open checks on one night and some of them were a fortnight old, sitting there quietly. An unpaid bill that stops drawing attention to itself is money nobody is going to collect.

Read it →

Cooking before the bill is paid

A bar tab means food starts before money changes hands. That is easy to say and awkward to build: the kitchen needs the order now, and the accounts must not see a penny until somebody actually pays.

Read it →

The receipt switch that printed anyway

Our payment screen had a Print receipt toggle from the day it was built. It was drawn, it flipped, it looked live — and nothing read it. The paper came out either way.

Read it →

A food hall is not one business

Seven kitchens under one roof share a landlord, a card machine policy and a set of opening hours. They do not share a receipt policy, a manager PIN, or a view about buzzers — and a POS that assumes they do will surprise somebody.

Read it →

A save that returns OK and writes the wrong row

The request succeeded. The screen said Saved. The value went to the wrong table entirely, and every test that checked the response was satisfied.

Read it →

A switch nobody hears is not a switch

The sold-out toggle worked perfectly — the database knew, payment refused — and the till kept selling the item for the whole gap in between. Where availability state actually has to live.

Read it →

The telemetry that never measured a till

We built speed tracking to catch slow tills. Two separate silent failures meant it only ever measured the back office — and nothing anywhere said so.

Read it →

A till that updates itself, carefully

We ship many releases a day; a till is opened once and left for a shift. How the register notices a deploy and reloads itself — and the six reasons it refuses to.

Read it →

Fifteen seconds to take it back

Finishing a ticket is the only irreversible press on a kitchen screen. Why the card goes green and waits — and why nothing reaches the server until the window runs out.

Read it →

The guest's menu is older than your shelf

A QR menu loads once and sits on a table while stock changes behind it. What has to happen when a guest orders a dish that sold out after their page loaded.

Read it →

What the first docket off a real printer taught us

The first paper off a real thermal printer failed three ways in one photo — mid-word breaks, code-page garble, two order numbers — and each fix made it honest.

Read it →

Order numbers a kitchen can shout

Five-digit references and platform codes make every handover a reading test. One three-digit number a day, reset overnight, is what a counter can shout.

Read it →

Sold out should warn the counter, not overrule it

The availability list can be wrong; the person at the shelf is not. A warning with an override and a nudge to fix the list beats a till that blocks the sale.

Read it →

Show the ticket's age, not the clock

A kitchen screen that stamps 14:07 on a ticket reads as fourteen minutes to a cook mid-rush. Age with units — 47s, 11m, 2d — is the number the pass runs on.

Read it →

A setting should show you what the guest will see

Every menu setting is a promise about someone else's screen. A live preview in the guest page's own layout shows the embarrassing pick before a customer does.

Read it →

Rank "popular" by takings, not by how many you sold

A most-popular rail sorted by units fills up with cheap sides. Sort it by what each item actually takes and the same shelf starts paying rent.

Read it →

A QR menu should offer the guest their own language — once

The phone already says what language its owner reads. What a menu should do with that, and the two mistakes: switching automatically, and asking every visit.

Read it →

Splitting a bill is three different jobs, not one button

Equal ways, by item, or by amount — each share with its own way of paying. What a till needs before "split" stops meaning "get a calculator".

Read it →

Opening a second food hall: the settings that have to split first

One building is a special case that hides everywhere. Receipt footers, buzzer rules and till PINs all have to belong to a hall before there are two of them.

Read it →

Your menu photos are probably hosted by a system you left

Switch POS and the pictures often stay behind — hotlinked to the old supplier until their servers stop answering. How to check, and what moving them takes.

Read it →

HelchPOS vs DINES: payments-first, or kitchen-first

DINES is a payment company with a POS on top. HelchPOS is a kitchen system that does not touch your money. Honest, including what DINES does that we do not.

Read it →

HelchPOS vs NOQ: the event platform, and the venue platform

NOQ runs festivals and events at scale, and processes the payments. HelchPOS runs the building the rest of the year. By people who moved a food hall off NOQ.

Read it →

HelchPOS vs me&u: the guest experience, and everything behind it

me&u is the QR ordering product we deliberately copy — and it has no POS, kitchen screen or stock system. What that means when choosing one for a food hall.

Read it →

HelchPOS vs peazi: the same QR menu, a different amount of product

peazi does QR ordering well and cheaply, and stops there. Where the two overlap, where they do not, and the one thing peazi has that we have refused.

Read it →

What a food hall owes its vendors, and when

Commission, recharges, VAT and the day the money actually lands. The arithmetic behind a vendor payout, and why the invoice matters more than the transfer.

Read it →

What "1.4%" actually costs you on a £5.90 pint

Card pricing is quoted as a percentage and charged as a percentage plus a fixed fee. At food hall basket sizes the fixed fee is most of the bill. Real numbers.

Read it →

Why "out of stock" should never stop your till taking money

A stock count is a guess about the world; the person at the till can see it. How to show stock on a till without a wrong number turning a customer away.

Read it →

Your kitchen screen and your till should be the same app

Two screens polling separately can disagree — that is the day a ticket goes missing. Why the pass belongs in the ordering app, and when a dedicated screen wins.

Read it →

Your gross profit number is only as real as your recipe lines

Supplier price, product cost, recipe line, menu cost. Most kitchens have the first two and nothing in the third — so the margin on screen is a dressed-up guess.

Read it →

How a food hall takes one payment across five kitchens

A guest buys from three businesses and pays once. What has to happen underneath for each kitchen to be paid the right amount — and where it usually goes wrong.

Read it →

25 questions to ask before you buy a food hall POS

A buyer’s checklist for multi-vendor sites — settlement, offline trading, allergens, stock, and the contract questions that decide how you leave.

Read it →

What happens to your festival bar when the signal drops

A field with 40,000 people on it is the worst coverage you will ever trade in. What offline mode must mean, and what separates resilience from marketing.

Read it →

Allergens on a QR menu: what UK law actually requires

Natasha’s Law, the 14 allergens, and which food must carry a full ingredient label rather than the information given another way — on a digital menu.

Read it →

One QR code for the hall, or one per stall?

Does the code on the table open the whole hall or a single kitchen? What each does to spend per head, to queues, and to the kitchens not on the poster.

Read it →