Role-Based Access Control That Scales Past Your First Enterprise Customer

The first enterprise customer that fills out a security questionnaire will ask a version of the same question: "can we define custom roles with granular permissions, and can we audit who has access to what?" A platform built with two hardcoded roles answers "not yet," and that answer has ended more enterprise deals than any pricing objection we have seen.

The model that holds up

• Permissions as atomic, named capabilities — `invoices.void`, `users.invite`, `reports.export` — not a handful of broad roles baked into if-statements.
• Roles as named, editable bundles of permissions — a customer-configurable layer on top of the atomic capabilities, not a fixed enum in your codebase.
• Resource-scoped permissions where they matter — "can edit this project" versus "can edit any project" is a distinction enterprise buyers actively look for.
• An audit log of every permission change — who granted what to whom, and when, queryable without engineering involvement.

The atomic-permissions layer is the piece worth building even if you launch with only two customer-facing role presets. It costs little extra at build time and it is the difference between "we can add a custom role for you" being a two-week engineering project versus a config change during the sales call.

Check permissions in one place

The same discipline that applies to tenant isolation applies here: permission checks belong in a single, tested authorization layer that every code path routes through, never scattered as ad hoc `if (user.role === "admin")` checks across the codebase. We have seen platforms with a dozen subtly different permission-check implementations across different features, each one a slightly different bug waiting to be found by a penetration tester.