Appropriate way to set up users / groups for shared development server

Over the past couple of months working on random website projects I've been developing a list of problems with my current configuration, as well as a list of desired features for my ultimate configuration -- however I'm not certain exactly how I should be setting up users / groups / permissions to get this working.

Desired Features

• One server
  • We will only be working on one or two projects at a time, and only people actively developing plus maybe one or two (for clients viewing work-in-progress) will be accessing the server. There is no reason to believe this server will get overloaded or that we'll need any form of load balancing
  • If the server did somehow get swamped momentarily (one developer is running a performance test while another simultaneously tries to spin up a new Foundation project or something) a 30-second load time on a page isn't world-shattering on a dev server
  • We're stingy and don't want to pay $5-10 per client for development when we could pay $40 flat fee for a sufficiently large server and stick 20 clients on it
• Separate users per developer
  • If we hire an independent contractor or employee who we then need to part ways with, we need an easy way to revoke their access rights to the development server. If everyone shares a login, this gets messy
  • For simple "best practice" security we feel every user should have their own passwords and SSH keys
• Multiple-user access to clients
  • Suppose the client "Example, Inc" with website http://www.example.com is set up by the user stevenbaett. Now we hire the independent contractor Bob Smith (user: bobsmith) to do some work for Example, Inc. If all of their code resides in /home/stevenbaett and was created by user stevenbaett, how can user bobsmith access any of it?
  • I feel like there should be a /clients folder, but how should permissions on it be handled? Should "owner" be stevenbaett and "group" be set to something like developers? Should "owner" be something else entirely? How can stevenbaett create a file under a different owner?
• Controlled access to clients
  • If bobsmith is given permission to work on Example, Inc that should not imply he has permission to work on OtherCompany, LLC. Somehow he needs access to the /clients/exampleinc folder without having access to /clients/othercompany even though stevenbaett will have access to both of these. How can this kind of per-user-per-client permission be set up?
  • Access should be revokable per-user-per-client. If bobsmith is finished working for Example, Inc then I should be able to remove his access to that folder without removing his access to any other folders
• We wish to set up a Cloud9 (https://c9.io/) workspace per client, within which we'll have multiple folders for their various projects

Problems we've encountered

• Server file access permissions
  • One site we work on uses Laravel (a PHP framework). Laravel provides a command-line tool called "artisan". If I run an artisan command while logged in as stevenbaett then the generated log file is owned by stevenbaett. If I then try to access the web server, Apache doesn't have permission to access the log file so it throws a 500 error
  • If I chown all of the files to www-data:www-data then Apache now works perfectly, but when I try to edit anything it fails saying that I don't have write permissions on stevenbaett
  • I can easily resolve both issues with chmod 777 *, however this is obviously dumb
• Cloud9 workspace set-up
  • This is less a Unix / Linux question and more of a Cloud9 question... Cloud9 lets you create a "workspace" which connects using a provided SSH key to a server then sets a provided directory as the root and allows you to edit files within this directory
  • In this way I could create a workspace called "example-inc" which mounts /clients/exampleinc and authenticates using stevenbaetts SSH key
  • Cloud9 also allows you to share these workspaces with other people who have a Cloud9 account. So I could give other people the ability to access this workspace... However if I do this, they are authenticating as stevenbaett! This means through terminal they have access to all the same files I do and they have all the same permissions I do
  • We want the use of Cloud9 to be optional (if we created one server user per client then we could have the workspace tied to that client's user and use workspace sharing as our only means of sharing access to independent contractors)
  • We also want to be able to collaborate on Cloud9, taking advantage of their in-workspace chat or other features -- which, from my understanding, requires sharing a workspace (and thus sharing whatever authentication the workspace is tied to)
• We need to be able to perform bulk operations across multiple clients / projects. For instance, we might search for all projects using a certain version of Laravel or do a mass delete of all .exe files or something.
  • This can be solved by logging in as root, but... is there a smarter way to do this?

So... what's the best way to set this up? Currently what I'm considering is creating one user per client AND one user per developer, then assigning the developers to one group per client they have access to. So /clients/exampleinc would be chown'd exampleinc:exampleinc and stevenbaett would be part of the exampleinc group (which can be revoked if he loses access). The C9 workspace could then be set up under the exampleinc user so it wouldn't have access to any other workspaces. However this doesn't solve the server permission issue, and I'm not certain if there are other issues I'd encounter which I haven't thought of yet.

Recent Questions...