Building software development kits (SDKs) is hard, complex, and a never-ending pursuit for some companies. Get it right from the get-go and you'll ensure:
● A great developer experience leading to higher usage resulting in quicker validation cycles ensuring faster commercialization and revenue generation.
Get it wrong, and you end up where companies meal kits do: not just with an annoyed cook, but with an upset extended family who are hungry and won’t stop telling the world about how you’ve ruined their lives.
A couple of those meal kit companies did get it right, and you know them well: Blue Apron, Hello Fresh, and Gousto. If you’ve used one of these kits, then you know two things to be true of these kits that apply to SDKs as well.
So we did what we do best. We brought our best people into a room (those who build SDKs and those who use them) and asked them to reverse-engineer what it takes to build the most amazing SDKs out there. They didn’t disappoint.
You’re not just competing with another company offering a similar solution. You are targeting a company with in-house dev. resources. So, in the never ending debate on “buy vs. build,” you're building a case in favor of “buy.” So, your case for speed to market, simplicity of use, ease of integration, and everything in between should be demonstrable in two 30-minute meetings.
Once you’ve established that your solution will require a developer on the client side, and the client will have developers on permanent staff, start building your SDKs from the first day. And in support of those SDKs, the developer microsite. You need this to establish user and market validation, because the entire Golden Path should be experience-able. Build the SDKs in parallelly with your core product, or risk having longer pivot and validation cycles and a harder time establishing product-market fit.
Your SDK should be integrate-able in under 15 minutes. If it takes longer than that, it’s a hard “No.” as a user. That means, when we build them, that’s the same kind of functionality and speed of integration we aim to deliver.
Some basic things we cover to ensure this: build SDKs in all the target industry’s most commonly-used programming languages, and ensure that they’re easily customizable. For example, Optimizely builds many elements of its SDKs as plug-ins to allow users to determine how and what they want to use. Another successful product like Zoom recognizes the importance of providing customizable SDKs to ensure the success of its video, audio, and instant messaging features’ integrations with other platforms.
Customers should also be able to leverage the SDK with minimal additional code-writing. If they have to write a lot of code just to integrate, the whole point is lost. Taking an example from the website world, when I’m coding a website’s front end, I need to write zero additional code to integrate with Google Analytics. That’s the ideal.
P.S. She has quite the encyclopedic knowledge about SDKs and always keeps us up to date.
I must pay and know that you are paying special attention to security protocols and measures. Vulnerability assessment and testing is non-negotiable. This SDK is going to be a part of someone’s source code and even the slightest vulnerability can be exploited. And, it has happened to some of the most secure and well-known SDKs as well. Remember the vulnerability in Dropbox’s SDK for Android and more recently, security vulnerabilities in Realtek’s SDKs for their WiFi modules that could impact over 200 IoT devices being made by over 65+ vendors?
One of the things that we do is run a scanner to detect any security issue early. codeQL, Sonar, etc. to name a few. In fact, our SDKs itself is set up to scan continuously to find and close vulnerabilities, not only with external library dependencies but within the product’s source code too. For example, if you are redirecting to an external URL from your SDK, the redirect will be subject to a thorough threat analysis. And it’s our (the team creating the SDK) responsibility to deliver that level of security.
What tangential functionalities can your SDK solve without increasing complexity? The core function of a user authentication SDK is to ensure that the id, the password, and the person is authenticated. But, in addition to that, how easy will it be to add two-factor authentication, or browser verification or even a captcha?
When doing end-to-end builds, I insist on additional discovery cycles and sprints to create product backlogs that identify tangential opportunities to solve and evaluate how easy it'd be to cover them with SDKs in initial launches.
It doesn’t matter what the leadership says, but downloads, performance, and bug report analysis come first. I’m scouring every developer forum, company-run communities, and sometimes even LinkedIn groups to ensure that we’re not going to be blindsided later on. So as an SDK builder, be active wherever your product is being discussed, solve those problems and bugs immediately, and respond. Otherwise, all I’m seeing are reports of bugs, and as far as I know, they're still unsolved.
P.S. She's our secret weapon; we sometimes bring her on early in the build cycle, cause if there’s anything weird to be found, she’ll find it.
The way you structure an SDK matters; its interface and the way the code is written should be self-explanatory to the developer deploying it. After working on the second on third use case, the developer should be able to make reasonable assumptions by looking at a new SDK code. For example, for one of our privacy compliance clients, we ensured that we wrote the entire SDK hierarchically with clean layers. This made plug-and-play customization easier, as well. Making sure it works isn’t enough; you have to be respectful of the source code that you'll now be a part of.
Is your SDK optimized to deliver value in the most efficient way possible? Once the SDK is deployed, it is taking up memory and computational space on your customer’s server. The SDK shouldn’t in any way be slowing down your customer’s product performance.
Let’s say that one of your SDK executions is spanning 100 threads (so running 100 times simultaneously, continuously). This uses up a lot of random access memory (RAM) resources. The question to ask: does the SDK really need to do this? A scan can detect high-resource consuming functions that might be running in the background or any unnecessary infinite loops to prevent such performance snafus after deployment.
Automate testing for the SDKs, pre-deployment. For every feature added, you're probably adding 10’s of use cases, and writing test cases for each one of those. Now imagine adding one more feature, adding another use case, and then you find out that the last deployed feature is no longer working right. That means, we’ve touched something that was supposed to be kosher. Pre-deployment testing should be automated to catch those kinds of flaws, early and quickly.
I have a seat at the table from when you start thinking of building SDKs. As a technical writer, I need to understand not just what you are building but why you are building it, and help you articulate all the possible use cases. Creating documentation that gives instructions on what to use and how to use specific SKDs is alright. But it still requires developers to investigate: when should I use this? I want to simplify even that.
I also participate in the user testing that follows. We do an internal round of testing for all SDKs and see if fellow developers can easily use and deploy the SDK. If they can’t, we go back to the drawing board to re-do the documentation.
So, if you are getting ready to build a product and deploy it for developers, the team above (or someone like them) is who you should have at your table. Cause, they'll be batting for you and will make a ridiculous number of things non-negotiable. And as much as we love trial-and-error, we avoid the error part for our clients, as much as possible.
If there’s an SDK out there that you love, ping us and let us know which one and why on LinkedIn.
