The Checkbox That Could Have Stopped the Till

I didn’t build anything new today. I went back and read what I’d already built — the sell screen, the cake orders, the sync engine, the lot — the way someone else would. It’s an uncomfortable kind of session, because the whole point is to go looking for the things you were pleased with a week ago.

The good news is the part I care most about held up. The sale is still sacred: a rung sale is written to the till’s own storage, forced all the way down, before the cashier ever sees a confirmation. The draft cart disappears in the same breath as the sale becoming permanent, so a phone that dies mid-tap can’t resurrect a cart that’s already been paid for. I went looking for a hole in that and didn’t find one.

Then I found something else.

The checkbox that could have stopped the till

Every completed sale went through the browser’s own little “Complete this sale?” pop-up. It seemed harmless. It’s been there since the beginning.

Here’s what I hadn’t thought about. When a page throws up a lot of those pop-ups, browsers start offering the user a tick box: prevent this page from creating additional dialogs. That’s a sensible feature for a dodgy website. On a till that shows one on every single sale, all shift, it’s a trap — and a cashier tapping it by reflex is not a stretch, it’s a Tuesday.

Once it’s ticked, the browser stops asking and just answers “no” on your behalf, forever. My code read that “no” as the cashier changed their mind, and quietly did nothing. No error. No message. Just a Complete button that stops working for the rest of the day, on a device with no obvious way back except knowing to reload the page — which nobody at a counter is going to guess.

Nothing would have been lost — the cart survives. But the till would have looked dead in the middle of a queue, and I’d have had a phone call I couldn’t explain. The confirmation is now a panel inside the app itself, so the browser has no say in it. Same question, same extra tap; it just can’t be taken away from me.

What stings is that I’d already worked this out once. The cake-order screen has a comment I wrote saying a pop-up like that is too easy to dismiss by reflex on a touchscreen. I fixed it there and never went back for the sell screen.

Money that only needed one tap

The cake orders let you take a payment against an order — a deposit now, the balance on pickup. That box would accept any number you typed and record it the instant you tapped the button. No confirmation, no upper limit. Type ₱5,000 instead of ₱500 and it’s done, and since payments can’t be edited, only voided, the slip sits in the day’s takings until somebody notices.

Every other money action on that screen already asked first. This one didn’t, and I don’t think that was a decision — I think I just didn’t do it. Now it asks, and says plainly when the amount is more than what’s still owed. It doesn’t stop you: overpaying is unusual, not impossible. Same rule as always. Warn, don’t block.

There was a second, meaner version of the same problem hiding behind it, which I only found going back over my own fix: two quick taps on that confirm button would have recorded the payment twice. The usual protection against double-taps doesn’t work here, because each tap mints a brand-new payment, so the server has no way to tell it’s the same one arriving again. Two real payments, from one slip of a thumb.

The back button that closed the shop

This one’s mine as a user, not a developer — I’d typed it into my own todo list at five in the morning, from the shop floor. On the phone till, pressing back from anywhere just closed the app. Not “go back a screen” — gone, mid-shift.

It’s now what you’d expect. Back walks you out one screen at a time — out of the order form, out of the order, out to the list, back to Sell — and only once you’re home does another press actually leave. Fiddly to get right, and I got it wrong twice before I got it right.

Two bugs I wrote while fixing the last one

Which is the honest part of the day.

My first back button worked perfectly for one press and then closed the app on the second. The reason was subtle enough that I’d have shipped it: backing out of the order form swaps one screen for another at the same instant, and my code was watching a number that didn’t change when that happened, so it never re-armed itself. I only caught it because I’d written a test that presses back three times in a row rather than once. Had I tested the obvious way, this post would have a sequel.

The second I caught re-reading my own work. I’d written a confident comment explaining why splitting the app into smaller pieces was safe — and the explanation was simply wrong. I’d claimed the offline cache covered the office screens; it doesn’t, and never did. Only the till. The change was still worth making, but it needed a safety net I hadn’t written, because a tab left open across an update would now break in a way it never used to. A wrong comment is worse than no comment: someone reads it later, probably me, and trusts it instead of checking.

And one thing I flagged turned out to be nothing at all — a case I’d already handled, sitting right there in the file. I’d skimmed a summary of the code instead of reading the code.

Smaller weights off the till

Three quieter ones. Searching a single letter used to draw most of the catalogue onto the screen at once, which the phone felt; it’s capped now, and says so. The till was re-downloading three months of finished cake orders every sixty seconds, forever, over mobile data — that’s a month now. And the app is split up so a small fix to the till doesn’t make every device fetch the entire thing again before it can update.

None of that is exciting. All of it is the phone in Labason running on a powerbank during an outage, doing slightly less work for the same result.

The whole session came to a handful of fixes, no new features, and a slightly shorter list of things I’m quietly assuming. I’ll take that. The most useful thing I did all day was write a test that pressed a button three times instead of once.