The feature nobody used was the broken one
We handed every write our system performs to a database and asked it to check them before anybody ran them. One had twelve columns and eleven values, and adding a supplier had been failing for a month without a single complaint.
There is a kind of fault that nothing catches, because the thing it breaks is the thing nobody does often. A till is used ten thousand times a week, so a fault there is on the phone within the hour. Adding a new supplier happens maybe once a quarter.
We spent a night pulling every statement our system sends to its database — every insert, every update — out of the source and handing them to a real database engine with nothing filled in, asking only one question: would you accept this?
Twelve columns, eleven values
One came back refused. The statement that creates a supplier named twelve columns and supplied eleven values. There is no clever failure mode here and nothing subtle to diagnose: the form errors, every time, for everybody, and it had been doing so since the day a column was added to the supplier record and the list of values below it was not.
Nobody had reported it. That is not a criticism of anybody; it is the shape of the problem. A venue sets its suppliers up in its first week and then adds one when it changes cheese wholesaler. Between those two events, the feature can be entirely broken and the business runs perfectly.
The same sweep found a chart stuck at nought
The second refusal was a report. A query grouping orders by their table was asking for a column called table_no; the column is called table_label. The database refuses the statement outright — but the code around it caught the refusal, quietly substituted an empty list, and the screen drew a perfectly convincing chart with nothing in it. The QR-ordering tab has been reporting a conversion rate of 0% for every venue, and 0% is a number you can look at for a long time without realising it is not a measurement.
That one is worse than the supplier form, because the supplier form tells you it failed. This one answered.
What to take from it if you run a venue
Twice a year, go and use the parts of your system you use twice a year. Add a supplier you will delete again. Raise a purchase order for one bag of flour. Open the report you only look at in January. You are not testing the software so much as finding out which of its quiet corners has gone dark while you were busy on the counter.
And when a number on a dashboard is exactly zero, treat it as a question rather than an answer. Zero is what a working system says when nothing happened, and it is also what a broken one says when it cannot tell.
Both statements are fixed, and the check now runs on every build: every write in the product is handed to a database before a release goes out, and a statement it will not accept fails by name.