Building fine-grained permissions
Most software does not need this. Three roles and one boundary is cheaper to build and easier to explain, and plenty of large tools ship exactly that. Their customers are teams working on shared material, where a designer who can also see the roadmap is not a problem anyone is trying to solve.
The business case for this platform names a different buyer. A marketing agency running a roster of clients, in the gap where the tools that manage many clients have weak AI and the tools with strong AI work one client at a time. The product is the intersection: one system that runs a whole roster and keeps every client's work separate.
The structure is not fixed
Giant Context is multitenant. An organization is a tenant, tenants cannot see each other, and a request naming an organization you do not belong to returns a not-found.
Inside an organization there are users, projects and apps, in any arrangement the customer wants. One project holding two websites. Ten projects holding one each. An email tool on one project and not on another.
An agency puts its whole roster inside one organization, so the tenant boundary sits around all of its clients at once. Separating those clients from each other is a second problem, solved further down.
And it has to hold whatever shape the customer builds. An agency with ten projects and one app each needs different boundaries than an agency with two projects and eight apps between them. A permission model that assumes a shape is wrong for half the customers who arrive.
The narrow grant
Everyone who works in an organization is a member of it. Membership anchors identity, billing and the audit trail.
Beyond that, access is attached one resource at a time. A contractor writing email campaigns for a single client holds a grant on the email app for that project and holds nothing else.
The rest of the organization does not render for them, does not appear in any menu, and returns a not-found if its address is guessed. There is no list of things they cannot open, because every screen is built from what the grants return.
What it costs
A coarse model stores a role on the membership. One row per person per organization, and every check reads that row.
This stores a grant per person per resource. A check joins the person, the resource being asked for, and the role they hold on it, on every request rather than once at sign-in.
The console carries the same weight. A member's page lists every project and every app with its own setting, and stays correct as customers add both.
The business case claims one system running a whole roster with every client kept apart. Per-resource grants are what make that true.
Without them an agency has two options. Give every person access to every client, which no agency with a confidentiality clause can do. Or open a separate account per client, which is the arrangement of separate tools the platform exists to replace.
Building something like this
I'm Jesse. I build platforms end to end, and I'm open to work. If this is the kind of engineering you need, get in touch.