Most products start with a role column - admin, manager, user - and a scattering of checks against it. It works for a year. Then a customer wants someone who can approve expenses but not view salaries, and someone else who can manage one region but not another, and the role list starts growing towards the number of customers you have. That growth is the signal that roles alone have run out.
The first structural improvement is to separate roles from permissions. A role becomes a named bundle of fine-grained permissions - invoice.approve, report.view, user.invite - and your code checks permissions rather than roles. This sounds like indirection and it is what lets you add a new role without touching any code, which is the point. Every check in the application asks whether this user may do this thing, never whether they are an administrator.
The dimension that actually breaks most models is scope. Permission to approve invoices is rarely global - it is for a department, a region, a project, a subset of accounts. A model that only answers what a user may do, without which objects they may do it to, forces the scoping logic into every query, where it will eventually be forgotten in one of them. Deciding early whether permissions carry a scope is much cheaper than adding it later.
Enforce in one place. Permission checks scattered through controllers, templates and background jobs will disagree, and the one that is wrong is usually the one nobody looked at - an export endpoint, an admin tool, a scheduled job. A single authorisation layer that every path goes through, ideally one that fails closed when it has no rule for something, is what makes the model trustworthy rather than aspirational.
Hiding a button is not a permission. Interface-level checks are a usability feature - they stop people trying things they cannot do - and every one of them must be backed by a server-side check on the endpoint, because the endpoint is what an attacker calls directly. The most common serious vulnerability in business applications is not a missing login; it is an authenticated user calling an endpoint intended for a different role.
Two things worth building alongside the model. An answer to why - being able to show that this user has this permission through this role in this scope turns support questions into a screen rather than an investigation. And an access review export, listing who has what, because enterprise customers and auditors ask for it periodically, and generating it by hand every time is how it stops being done.
