Start from real people, not generic labels
"Admin" and "user" are rarely the whole story — map the actual people who'll use the application and what each genuinely needs to see or do, then derive roles from that, not the reverse.
The minimum viable role set
Most applications need at least three: someone who manages the whole system, someone who manages their own data/clients, and someone (a client or external user) who sees only their own slice — see Client Portal Development for a worked example of this exact three-tier pattern.
Permission boundaries, not just role labels
A role name isn't enough — each boundary (can view X, can edit Y, can approve Z) needs to be explicit, especially anywhere billing or sensitive data is involved.
Designing before building, not after
Retrofitting roles into an application built without them is expensive — this gets mapped during the Product Scope conversation, before development starts, not discovered mid-build.
Questions
Can roles be added later if we start simple?+
Yes, but it's cheaper to plan for the roles you already know you'll need than to retrofit them after launch.
Do all applications need multiple roles?+
No — a single-role MVP is often correct at first; see What Should Be Included in an MVP for when multi-role support should wait.
How granular should permissions be?+
As granular as a real, named risk requires — not more, since excessive granularity adds maintenance cost without benefit.