Scaling project-based permissions: team per project vs direct doc permissions?

I’m building an app on Appwrite and want to double-check if my current approach is the right one before I go all in. I’ve read through the documentation, but I’m still not 100% sure what the best practice is here.

My setup / requirements:
• I have Projects, each can have one Customers, multiple Suppliers, and multiple Issues/Tasks.
• A Project always belongs to exactly one creator, but many people can be assigned to it (internal users, customers, suppliers).
• I want document-level security only: either you have access, or you don’t. No partial fields.
• If someone is assigned to a Project, they should automatically get access to all related docs (issues, linked customers/suppliers, etc.).
• Permissions should be revocable in one place (remove them from the Project, they instantly lose access everywhere).
• I don’t need anything fancy like per-field security. just binary access.

My current thinking:
• Right now I auto-create a team per user at signup and stamp that team on all docs. But I realize that doesn’t scale for sharing.
New idea:
• Create a Team per Project (proj_).
• Add all people (internal, customers, suppliers) as members of that project team.
• Stamp read/write("team:proj_") on all project docs.
• Use link collections for many-to-many (e.g. ProjectCustomer, ProjectSupplier) so I don’t have to union dozens of teams onto one customer/supplier doc.
• Optional org_admins team for global admin visibility.

My question:
• Is one team per project the best practice for this use case?
• On the Pro plan, can hundreds of teams (e.g. 100 users × 10 projects/year) scale well?
• Are there any hidden limitations around memberships or queries that I should be aware of at this scale? I saw that no limitations are on teams creating
• Or would it be smarter to only set permissions directly on the Project doc and then handle access to linked entities differently (instead of carrying the team on every single related document)?

Thanks for your time

From what I understand, an user could have multiple projects and a project could have different permissions based on roles (like owner will have full CRUD, supplier read only X things, etc).
I think that probably the team approach is the best

Yeah exactly, mostly just CRUD ops for everyone, nothing fancy.
So you don’t see any issues if I just spin up a team for every project and use that for perms? So lets say 100 projects would be 100 teams and so on ..
Also that means in worst case if a supplier is assigned to 100 projects, the one supplier would have 100 teams in the permission