(apologies in advance if this feedback is too low level, but here goes…)
I’ve been in the process of setting up a Shotgun Toolkit pipeline in a studio with an existing pipeline (which already uses Shotgun for tracking). We’re not fully up and running yet but I can share a few things that have come up so far, both from users and myself doing the dev/setup. I’ll continue to add to this thread when I remember more things too! 
Development docs
Module documentation is generally quite good but it would be great to have more of an overview that describes how all the parts fit together, from a technical perspective, but at a higher level than just the python modules. It has taken me a while to really ‘get’ how toolkit works internally, but things are coming together more easily the more I understand the big picture.
One thing that took a while to understand is knowing what code is actually being run and when. Now I understand that the apps are downloaded into ~/.shotgun/bundle_cache and that the core sgtk modules are in ~/.shotgun/p{project_id}.plugin_id.* it feels less like spooky action at a distance.
Something that doesn’t help here is outdated documentation floating around the internet (including old posts on shotgun-dev etc). I always have to approach everything I read with a bit of skepticism since it seems many methods and recommended ways of doing things have changed over the years.
I’m using an uploaded configuration and much of the info I’ve found online barely touches on this, if at all. I assume it’s because this is new but it makes things difficult. I don’t know if this is specific to my site here, but the plugin id and uploaded config columns don’t even show up by default in my Pipeline Configurations tab. The SG Desktop Advanced Project Setup doesn’t clearly refer to it either.
Render farm usage
It’s commonplace to want to shove as much processing as possible on the render farm, not users’ machines, and to use the farm to automate procedural pipeline processes. It seems that Toolkit hasn’t really been designed that much with a farm in mind. I can understand this since it needs to be workable for all types of studios, including those without farms, but it would be great if it supported farm workflows better out of the box.
For example the out of box workflow of needing to convert Nuke write nodes or Houdini ROPs to the stock versions before sending to the farm is really nasty for the user and adds manual processes that can be error prone, to what should be easily automated. On the flip side, the SG Write Nuke node hides useful parameters that are on the default write node, and same with the Houdini SG Mantra node (when it’s a hardcoded HDA from Shotgun it won’t update with new features in new Houdini versions).
Most (larger) places that I’ve worked at have usually had things set up so that you can expect a farm blade to have access to the exact same software environment and let you do the same things as on a local workstation. If this is not the case it can make things a bit of a nightmare to debug. In our case here it’s taken me quite a bit of pain and effort to set up a bootstrap system on the farm so we wouldn’t have to do the SG node conversions and to allow us to use the SG context to run procedural processes on the farm. I’ve also ended up duplicating/extracting some of the python code from the SG mantra ROP and just using that as default parameter expressions/spare parameters on the default Houdini Mantra ROP, to get the best of both worlds (access to shotgun context + not stuck with SG nodes). I’m a bit concerned about what might happen when things get going though since I’m told this could hammer shotgun too much and get slow. For now this is the best I’ve got out of some imperfect options.
The other main thing we’re missing is being able automatically create Versions from Nuke or Houdini renders with associated Quicktimes automatically after they are done on the farm. Currently it looks like this has to be somehow done manually with the SG QuickReview, or I’ll have to try and script something with Deadline Draft etc. This is a vital part of our workflow and it would be nice if it worked more seamlessly out of the box.
, what kind of things are you looking to do… especially those that target those devs just looking to get started with sgtk without needing to know everything?