A name your code makes up as it runs
We cut 112 KB off the register by removing the styling it can never use. The method nearly deleted the one rule that turns a low-stock chip amber, because that rule name is never written down anywhere.
Our styling lives in one file for the whole product — back office, kitchen screen, register. The register downloads all of it to draw a keypad, a grid of tiles and a payment screen, and most of what arrives describes back-office screens a till can never reach.
So we built the register its own copy: the same rules, same order, minus the ones no register screen can match. Measured over the wire on the live site, that took the download from about 150 KB to 36 KB — 112 KB that a phone opening the till cold no longer waits for.
The obvious method has a hole in it
To decide which rules to keep you look at what the register's own code mentions. If a rule is about something no register file ever names, the register cannot match it, so it can go.
That works until a name is assembled while the program is running. One line in our till builds the little stock chip on a tile by gluing a fixed prefix to a value that arrives from elsewhere. If the value is "out" the name ends up as one thing; if it is "low" it ends up as another. Neither finished name appears anywhere in the source, because neither is ever typed.
The first cut of our method kept the out-of-stock rule and dropped the low-stock one. Not because it judged them differently — because the phrase "out" happens to be spelled out somewhere else in the codebase and "low" does not.
What that would have looked like in a venue
Nothing. No error, no blank screen, no message in a log. A tile that should carry an amber "3 left" chip would carry a grey one. The information is still there, the urgency is gone, and the only person who could notice is a cashier who had seen the amber version and thought "that looks different today".
This is the shape of bug we find most often and like least: the software does not break, it just quietly stops saying something.
Two rules we now follow
The first is mechanical. When a name is built from a fixed part and a variable part, the fixed part is what you keep — the whole family, not the members you can find. Same for a name built the other way round, with the variable part first.
The second is about evidence. We do not trust the method, we check the result: the register is driven in a real browser on desktop and on a phone, through the sale, the payment screen, the kitchen board and the signed-out keypad, and every element's appearance is compared against the same page using the full styling. Twenty screens, 3,696 elements, no differences.
That check earned its keep immediately. It found a second fault we had not suspected, in the part of the process that removes unused animations, which was silently taking working rules with it.
If you are buying
Ask how anyone would know if a screen quietly lost a detail. "We have tests" is not the answer — a test suite that checks what a function returns has no opinion about whether a chip is amber. The answer you want involves looking at the actual screens.