The drawbacks for SDKs I see: * Needs to break the SDK containment. If you want to add some "off the menu" feature, you might be able to extend the SDK itself

The drawbacks for SDKs I see: * Needs to break the SDK containment. If you want to add some "off the menu" feature, you might be able to extend the SDK itself, butsuddenly you're running a fork that can't be maintained and updated with other dependencies. * Potential for compatibility timebombs. If you use a deprecated language feature in the SDK, or a hard-coded certificate that expires 2028-01-01, it forces a full-scale upgrade event for developers rather than fixing a single API call in their own code. In the worst case, this triggers a whole avalanche of dependency updates and breaking unrelated code. * Design impedance mismatches. Maybe you're writing procedural code and the SDK is object-oriented, or maybe it's just exposing a data structure paradigm that needs a lot of data reformatting and glue to work. A good SDK is nice to have, and if done right can be a good reference implementation for the API too. But make sure there's a usable public API under there too.