feat: Users expect to have organization/account based access control

[eseidel]

Right now Shorebird "collaborators" are done on a per-app level. This is unexpected for many customers where often it's the finance department or CEO or whatever who makes the account/sets up the billing and then expects to be able to share access to the account (while maintaining control over the billing and access).

See also:

• current docs: https://docs.shorebird.dev/teams
• Similar problem with app-groups/flavors: https://github.com/shorebirdtech/shorebird/issues/1429
• restricted-permission collaborators: https://github.com/shorebirdtech/shorebird/issues/1337

[eseidel]

We've had 2-3 of these in the last 2 weeks. The pattern is that the the CEO (or other billing-controlling but non-app-developing person) signs up, and is then confused that they can't add someone as a collaborator (they don't have any apps yet) and even if they did add a dummy app, they can't allow the person actually in control of their app's source code to create new apps on the correct billing account when necessary.

The workaround we've been using for now is to move the stripe customer id to whoever is in charge of the app, although that's not always helpful, since that person could be a temporary contractor or agency.

[felangel]

Do we want to introduce a concept of projects/organizations at this stage? We can support both (similar to how GitHub has repos associated with an account and repos associated with an organization).

[eseidel]

I suspect it's too much complexity to bother with for now. We just need to wait for this need to get more dire and then do whatever the minimum needed to support non-engineers signing up and controlling billing separately from whoever is doing the app releases.

[eseidel]

Dupe with https://github.com/shorebirdtech/shorebird/issues/739?