The HR system I built has three kinds of users: employees, managers, and HR. Each sees a different app. The wrong way to build that is a pile of conditionals scattered across every screen.
Decide access at the edge, not in the UI
Every request carries the user and their role. The API decides what that user is allowed to touch before any handler runs. The UI never guesses; it only renders what the API already permitted.
That single boundary means a new screen cannot accidentally leak data. If the API says no, there is nothing to render.
Model permissions as data
- Roles map to a small set of capabilities, not to screens
- Screens ask "can this user approve leave?", not "is this user a manager?"
- Adding a fourth role later is a data change, not a rewrite
When permissions are data instead of branching logic, the tangle never forms. The code stays boring, which is exactly what access control should be.