# Two roles were not enough.

Permissions rebuilt as role-based access control around the 5 personas who use the platform, so enterprise teams could onboard without hand-holding.

Company: VectorShift

Contribution: Permission-system redesign

Company tenure: VectorShift · Jul 2025–present. This is not a claim about individual project dates.

Context: 5 platform personas

## TL;DR

Problem: A generic admin/member split did not match how enterprise teams work, so sharing and onboarding needed hand-holding.

My call: Rebuild permissions as role-based access control mapped to the 5 personas who actually use the platform.

Outcome: Enterprise accounts could finally share work and onboard on their own. Security complaints went down.

- Generic roles → persona roles: 2 → 5
- Workspace, project, user features: 3 levels
- Security complaints: Fewer

## Context

- Company: VectorShift (YC S23), multi-tenant enterprise platform
- My role: Redesigned the permission system
- Users: The 5 personas who use the platform, and the admins who manage them
- Trade-off: Chosen over flashier feature work

Conceptual multi-tenant hierarchy with five persona roles. Persona names and real access assignments are not shown.

## The problem

Permissions had two roles: admin and member.

An enterprise account is not two kinds of people. A fund has partners who need to see everything, analysts who build, outside advisers who should see one project, and IT staff who manage access but should not read deal data.

With only two roles, sharing work and onboarding a team needed hand-holding from us. I picked this over more visible feature work, because it was blocking adoption of those features.

Evidence: Enterprise onboarding needed hands-on help. Security complaints were coming in. The complaints came from accounts whose structure the two-role model could not express.

## Constraints & non-goals

Multi-tenant. Permissions have to work across workspaces, projects and user-level features.

Roles map to the 5 real personas, not an abstract list of permissions.

Existing accounts move over without anyone losing access they depend on.

Out of scope: A fully custom permission builder for every user. Field-level permissions on individual data points. Changes to single sign-on or identity providers.

## Options I weighed

Rejected: Add a few more fixed roles to admin/member Each new role would patch one account’s problem and confuse everyone else.

Rejected: A fully custom permission builder Maximum flexibility, but it hands the hard design work to the customer’s admin.

Chosen: Role-based access mapped to the 5 platform personas, across a multi-tenant hierarchy Roles people recognise make the default right for most accounts, without configuration.

## The spec

Users: The 5 personas who use the platform. Account admins who manage access.

Requirements: Roles map to the 5 platform personas. Permissions apply across workspace, project and user-level features. Admins can see who has access to what, and why.

Acceptance criteria: A new team member gets the right access from their role alone. Sharing a project with someone grants exactly what their persona allows. Migrated accounts keep the access they already had.

Guardrails: No permission change can widen access silently. Access-related support tickets are tracked before and after launch.

## What shipped

1. Map personas. Start from the 5 personas who actually use the platform.

2. Structure. Build a hierarchy across workspace, projects and user-level features.

3. Assign. Each person gets a persona role, which sets their access at every level.

4. Share. Teams share work across the account without asking for help.

## What changed

Enterprise accounts could share work and onboard without hand-holding.

Security complaints went down.

Larger teams could start adopting the more visible AI products.

These are qualitative outcomes. I don’t have a measured reduction in onboarding time to report.

## Reflection

AI products still depend on ordinary foundations. Permission design decides whether an enterprise can adopt the visible features at all.

If I did it again, I would publish the persona-to-role mapping as customer documentation at launch. Admins trust a permission model faster when they can read the reasoning behind it.

The takeaway: Model access around the people using the platform.

Last updated: 2026-09-13