Signing in is not the same as getting in

A new manager rings you on their first morning and says they are logged in but there is nothing there. You picture an empty database. What actually happened, more often than you would think, is that the sign-in worked and the permission behind it did not.

We found exactly that in our own product last week, on the one screen nobody ever retests: the very first account a brand-new site creates. It signed in. It got a session. It was handed a working app. And every screen inside answered no, because the role written on that first account was a word the permission code had never heard of.

Why it survived so long

Because it is invisible from the only place anyone looks. Our own account was set up years before and has the right role. The check that creates a first account refuses to run once anybody exists, so no established venue can ever trigger it. The only people who could see it were the ones with nobody to ask — somebody setting the thing up alone, on a Tuesday, who concludes the product is empty and closes the tab.

What this means for your venue

When a member of staff says "it's not working", the first question is not what is on screen. It is: did it let you in, or did it let you in and then show you nothing? Those are two different repairs. The first is a password, a code, a device. The second is a role — somebody was added to the rota but never granted the venue, or granted one site when they work across three.

And if you are the person who set the venue up, you are the account nobody tests. Give yourself a second, ordinary staff login and open the app with it once a month. Walk the screens a chef or a counter manager actually uses. It takes four minutes and it is the only way to see what they see.

The general version

Any check that runs once, at the beginning, and then locks itself out is a check with no witnesses. First-run setup, the first stocktake, the first end-of-day. Nobody runs them twice, so nobody finds out they are broken until a stranger does. Those are the ones worth deliberately re-running on a spare venue before you need them.

Our own answer was to build a test that creates that first account the way a real browser would and then opens the six screens a new owner lands on — and, just as importantly, to pair it with an account that should not get in, so "the screens answered" cannot quietly come to mean "nothing is being checked".