The Worst Time to Design Permissions Is After You Land an Enterprise Customer

Introduction

Nothing exposes lazy permission design faster than an enterprise customer with real organizational complexity.

Up to that point, a lot of products get away with broad roles and optimistic assumptions:

• admins can do basically everything
• members can do most things
• support has a few internal superpowers

Then an enterprise prospect asks for department-level controls, approval boundaries, auditability, delegated administration, and the ability to separate who can view something from who can mutate it.

Now the team has to discover whether the product actually has an authorization model or just a handful of convenience checks.

This article is for teams shipping SaaS products that still treat permissions like a thin UI concern. Enterprise does not create the need for serious access control. It just removes your ability to ignore it.

The Core Judgment: Permission Design Gets Exponentially More Expensive Once Assumptions Are Baked Into Workflows

This is why late-stage access control work feels miserable.

Permissions touch:

• data visibility
• action eligibility
• admin experience
• audits
• internal tooling
• API behavior

If the product was built around “trusted user” assumptions, adding nuance later is rarely a small patch.

It often means unwinding business logic that assumed broad access from the beginning.

How This Breaks in the Real World

The pain usually shows up in one of three ways:

• visibility and edit rights were never separated
• account-level roles were used where object-level rules were needed
• internal support shortcuts bypassed the same controls customers now care about

That is how teams discover they do not really have RBAC or authorization strategy. They have convenience defaults.

And once those defaults are embedded across UI, APIs, and jobs, cleanup gets expensive fast.

A Real Example: One “Admin” Role Was Doing Ten Different Jobs

I watched a product try to satisfy enterprise requirements with one oversized admin role that had accumulated responsibility over time.

It could:

• manage billing
• change account configuration
• approve workflow actions
• view sensitive exports
• manage users

That was fine right up until a customer wanted those responsibilities separated across actual teams.

At that point, the product team was not adding a feature. It was redesigning assumptions that had spread everywhere.

The earlier they had modeled privileges more explicitly, the cheaper that future would have been.

What I Would Do Instead

I do not think every startup needs enterprise-grade authorization on day one.

I do think products should avoid painting themselves into a corner.

That usually means:

• separating viewing from mutating early
• keeping role checks closer to business rules than to UI display logic
• avoiding giant catch-all admin roles when responsibilities are clearly different
• thinking about audit trails before big customers ask for them

The goal is not overbuilding. It is avoiding a model so simplistic that growth becomes a rewrite.

Closing

The worst time to design permissions is after enterprise revenue makes the problem urgent.

By then, the system is already revealing what it assumed about trust, power, and visibility.

Better permission design does not only protect the product.

It protects your future from becoming a very expensive cleanup project.