Why we completely abandoned custom user roles for early accounts.
by•
We spent three weeks writing granular permissions—allowing team admins to assign custom read, write, and edit access for every single module. When we analyzed usage two months later, over 95% of workspaces were just using standard default roles.
Early-stage software needs sensible defaults, not complex configuration settings that slow down onboarding.
14 views
Replies
For me this feels like a massive validation because we recently stripped out half our custom settings and our activation rate jumped almost immediately.
tested a similar approach on our new module and stripping away configuration overhead has completely changed how fast users reach their first aha moment.
Agree on defaults. One thing worth keeping from those three weeks: make sure the simple roles are enforced on the server, not just hidden in the UI. When teams cut a permissions system back to defaults, the menu items disappear but the endpoints behind them sometimes stay open to every role. A quick test catches it: log in as a viewer and call an admin endpoint directly. If it works, the role only exists in the interface.
acording to me the biggest takeaway here is learning to trust the data over what loud prospective enterprise clients say they need during discovery calls.
I have been wondering how you handled edge cases where a beta client specifically threatened churn unless they got custom permission controls during intial sales calls.