One Shot ships two roles today, `member` and `admin`, and one user per account. That's a narrower
model than most SaaS products eventually want, and it's narrow on purpose: it's the smallest thing
that's correct, with a documented path to grow past it without a rewrite.

## What exists today

`User#role` is either `member` or `admin`. There's no admin UI: an admin operates on data through
`bin/rails console`, working through an account the same way any other code does
(`account = Account.find(...)`). The main thing `admin?` does today is exempt an account from
entitlement checks, so an admin can reach a paid controller without a subscription; see
[Authorization](/docs/core-concepts/authorization). You can extend the same flag to gate an admin
area of your own if you build one.

Because there's exactly one user per account, "who's on this team" isn't a question the app has to
answer yet. The account *is* the user, for authorization purposes, and every policy, every scoped
query, and every billing check already keys off `Current.account` rather than `Current.user`. That's
the distinction that makes the next section additive rather than disruptive.

## Adding real multi-user teams

When you need more than one person sharing a workspace, the model doesn't need to move much,
because everything already scopes to the account rather than the user:

1. **Add a join model with a role**, something like `Membership`, joining `account`, `user`, and a
   `role` column (`owner`, `member`, whatever your product needs). Let `User` belong to many
   `Account`s through it.
2. **Add `owner_id` to `Account`**, and set it to today's implicit single user so existing accounts
   keep working with no migration of behavior, only of data.
3. **Add an account switcher** in the signed-in UI that sets `Current.account` to whichever
   workspace the user picked. This is the one new piece of session state; everything downstream
   already reads `Current.account`.
4. **Build the invite flow**: an invite record, an email, and an acceptance path that creates the
   `Membership`. This is genuinely new work, unlike the first three steps.

What you will *not* need to do: touch every model to add a new scoping column, rewrite policies
that already filter through `ApplicationPolicy::Scope`, or change how billing attaches (it's
already on `Account`, not `User`, specifically so a shared subscription needs no rework). The
tenancy boundary was the expensive decision, and it's already made; see
[Accounts and Tenancy](/docs/core-concepts/accounts-and-tenancy) for why it was made this way from
the start.

## Next

With the domain model clear, see how to add a feature on top of it:
[Adding a Resource](/docs/building-features/adding-a-resource).