There is a reliable way to tell whether a system was designed with security in mind or had it added later: look at where access decisions are made.
Client-side checks are UI, not security
Every system eventually has more than one kind of user — an admin, a staff member, a client, someone from another department. If the app decides what each of them sees by hiding buttons, security is a UI concern, and UI is trivially bypassed. Hidden buttons are a courtesy, not a boundary.
Real access control lives on the server. Every request for data answers the question "is this user allowed this record, this operation?" before anything is returned or changed. The interface can then show or hide whatever it likes — the decision has already been made where it cannot be bypassed.
Default deny, then grant deliberately
The safest starting posture is that nothing is accessible, and access is granted deliberately, record by record, role by role. The inverse — start open and restrict later — guarantees that the restrictions are incomplete, because nobody remembers every path data can travel.
It is the same principle as file permissions, bank vaults, and good frontend state: deny by default, grant explicitly.
It is cheaper on day one
Retrofitting access control means auditing every existing path, migrating data that was visible when it should not have been, and living with the doubt that something was missed. Building it in from the first commit means every feature since then was designed inside a boundary that already existed.
Security claims require evidence. The evidence starts with where the decisions are made.