Drindal is really good at doing what it's built to do and we have a lot of plans for more features. You'll get the most out of it if you follow a few guidelines so you're on the same page with us as we continue on our roadmap.
Drindal doesn't have concepts like "projects" built in. Tags serve the same purpose and more. Use them to mark tasks any way you like. A tag named "customer" can be used with a value that is the customer name on every task associated with a customer. A "project" name can be used to mark tasks for certain projects. Then use filters to view all the tasks matching certain tags or tag values, effectively getting all the tasks for a certain project, customer, etc on a "Project A" or "Customer X" board.
If teams use the same naming convention for their sections, it will be easier to build views showing tasks for multiple teams.
Track work that needs to get done as tasks, not comments on tasks. Use comments for events, conversations and details that are leading to the completion of the task. Tasks should get created, worked on and then moved to a "done" section when they are complete. Use workflows if you have recurring tasks so a new version of the task gets created when the first version is complete. Don't keep a perpetual task open and keep updating a never ending list of comments as recurring work is done.
For example:
A task to "Check in on Customer X" scheduled for the 1st of the month. Once you call the customer and check in, add a comment about the conversation, make new tasks for any new work that needs to be done and close the task. If the customer was good and didn't need anything, make a new task for checking in the 1st of the next month. Don't add a comment the call was made and then move the same task back to the backlog to add another comment in a month. A workflow can create the new task automatically for you.
Tasks form a history of work that happens for the customer in this case.
If you have the same group of users that works on 4 projects, don't create a team for each project. Create a single team for the users and use a "project" tag with the project name as the value to mark tasks with the associated project. Create a filter for each value of the project tag if you want a view for each project's tasks alone.
When creating teams, think about who needs access to a group of tasks. When a user is added to a team, he has access to all the tasks for that team. There are elevated team privileges reserved for team admins but generally Drindal assumes team members can trust each other.
Drindal assumes a user will only be a member to teams she actively participates in. This would imply she won't be a member of a large number of teams since there is only so much time in a day and also that a team won't have a large number of users since there would be too many "cooks in the kitchen".
For example:
Don't create a company wide team in your enterprise org to let people see what product is up to.
Don't add your CTO to all the teams because she likes to know what's going on. Drindal will have reporting features to solve this kind of requirement.
Do add users to a team when they regularly create tasks and finish tasks for that team.