Let the server be the referee
What multiplayer games taught us about business software: check every rule where nobody can tamper with it, and send people only what they may see.
Online games are a brutal teacher. Put a word game or a card game on the internet and, sooner or later, somebody will try to cheat. They’ll open the browser’s developer tools, poke at what the page received, and send the server things the interface would never allow.
Building Anagrid and Muggins taught us two rules that apply just as much to business software, where the stakes are money and private data instead of bragging rights.
Rule one: check everything on the server
In Anagrid, players build crosswords from a shared pool of letter tiles. Whatever the screen lets you do, the server checks every word and every tile again, because anything that runs in someone’s browser can be changed by them. The interface is a convenience; the server is the protection.
The business version is the same. A form that hides the “discount” field from junior staff is not a permission system. A page that greys out the “approve” button is not an approval rule. If the rule matters, the server enforces it, every time, whatever arrives.
Rule two: never send what they shouldn’t see
In Muggins, an online cribbage game, the server never sends you your opponent’s hand. Not hidden, not encrypted, not “we trust the interface”. It simply isn’t there to find.
This one is easy to get wrong in business software. A list page loads every customer and filters them on screen. A report fetches all the salaries and shows only your team’s. It looks right, and everything is one click of the developer tools away.
The fix is to decide, on the server, exactly what each person is allowed to see, and send only that.
Why it’s easier to build in than to add
Both rules are cheap at the start and expensive later. When the server is the referee from day one, each new feature just follows the pattern. When it isn’t, every screen has to be re-checked once someone notices, usually after it matters.
So we build them in, even for internal tools used by five trusted people. Partly because trust changes, and partly because the same structure gives you something else for free: a single place where the rules live, which makes the system easier to reason about and to test.