SDK

What is an SDK?

SDK (software development kit) denotes a collection of program libraries, documentation, sample code and tools for developers. Program libraries are ready-made, reusable code components. With an SDK, developers create software for a particular platform or integrate a third-party service into their own product. Unlike a web interface that runs on the provider's servers, an SDK is built into the user's software and delivered with it. It can be pictured as a construction kit: instead of making every part itself, the developer receives prefabricated parts with assembly instructions that fit exactly one system.

SDKs come in two basic forms. Platform SDKs are provided by manufacturers of operating systems or devices so that third parties can develop applications for them. Service SDKs are offered by providers of payment, analytics or identity services to simplify connection to their programming interface (application programming interface, API). In funding rounds and company sales, the SDK is of interest as a sales instrument, as a separately licensed product and as a source of dependencies and data flows.

Structure and relationship to the API

An SDK typically contains ready-made functions for the most important calls of a service, management of access credentials, understandable error handling, sample applications and often a test environment without real data. It is produced separately for each supported programming language or platform, for example for mobile operating systems, web applications and server software.

The programming interface determines which requests a service accepts. The SDK relieves the developer of having to assemble these requests themselves. This shortens integration time considerably but also makes the customer dependent on the provider's versions and maintenance of the SDK.

Business models

• SDK as a sales instrument: The SDK is free; what is charged is use of the service behind it. The easier the integration, the more integrations arise and the higher the customers' switching costs.
• SDK as a licensed product: The SDK itself is licensed, for example per application, per device or per active user. This is common for functions that run locally on the device, such as image processing or document capture.
• SDK as part of a platform: Platform operators provide SDKs so that third parties extend their ecosystem. More third-party applications attract more users and vice versa; these are indirect network effects.

Each supported language causes permanent effort for releases, tests and security updates. For valuation, the number of active integrations and their development over time therefore count for more than the number of languages.

Licence, liability and data protection

Because the SDK is distributed to end users with the customer's software, the customer needs a right of use that covers this distribution. The licence terms regulate in which products the SDK may be used, whether modifications are permitted and what applies at the end of the contract. If the SDK contains open source components, their licence obligations apply on every distribution, that is, for the provider and for every customer that ships the SDK with its app. Components under a strong copyleft licence are particularly delicate. Such licences permit distribution of software built on them only if its source code is also disclosed, that is, the readable program code behind it. Customers would then have to release their own source code or remove the SDK, which is a considerable business risk for an SDK provider.

Anyone who builds in third-party SDKs takes on their risks. Analytics and advertising SDKs in apps frequently read information on the end device and transmit data to third parties. Under Section 25 of the German Telecommunications Digital Services Data Protection Act (TDDDG), access to the end device is in principle permissible only with consent, unless it is strictly necessary for the requested service. For the onward transfer of the data, the requirements of the General Data Protection Regulation (GDPR) also apply. A security vulnerability in a widely used SDK affects every application that contains it, while the provider's liability is usually narrowly limited in its licence terms.

Review in due diligence

If the target company itself offers SDKs, buyers and investors check in due diligence, the investigation before the transaction, above all:

• the licence terms towards customers, including limitation of liability and transferability,
• a software bill of materials, that is, a list of all third-party components included with version and licence,
• the number of active integrations and the share of installations on maintained versions,
• the process for security updates and the speed at which customers adopt them.

If the target company uses third-party SDKs, an overview with provider, purpose, licence and data flows, together with the associated contracts, belongs in the data room, the protected collection of documents for the reviewers.

Practical example

A software company offers automatic capture of identity documents. Banks, insurers and rental platforms build its SDK into their apps. Billing is per successful verification via the interface; the SDK itself is free. About 120 customers have built it in, and the number of active integrations grew by 30% in the previous year. A strategic buyer, that is, a company in the same or an adjacent industry, reviews the company before an acquisition.

• The software bill of materials shows an image-processing library under a copyleft licence in the SDK for mobile devices. The company replaces it before signing (signature of the purchase agreement) with a component under a permissive licence.
• About 40% of the active installations run on versions that are more than two years old and no longer receive security updates. The buyer demands a plan to migrate these customers within one year.

In the purchase agreement, the buyer secures itself through a warranty on compliance with all open-source licences and an indemnity for claims arising from the replaced component. The number of active integrations and their growth feed into the valuation as evidence of customer retention. None of the findings endangers the acquisition, but both could have been dealt with before the sale with a maintained bill of materials and a rule for switching off old versions.

Distinction from related terms

• API: the interface through which a service is addressed. It stays with the provider; the SDK is the aid on the customer's side that operates this interface.
• Program library: a single component with reusable code. An SDK usually contains several libraries, supplemented by documentation, examples and tools.
• Framework: dictates the structure of an entire application. An SDK, by contrast, is inserted into an existing application.

Common mistakes

• Too many platforms too early. Several inadequately maintained SDKs cause more support effort and security risk than a single one that works reliably.
• Missing transition periods. Anyone who switches off old SDK versions without lead time interrupts customers' applications and endangers contract renewals.
• No overview of third-party components. Without a software bill of materials, it cannot be demonstrated which licence obligations are passed on to customers with the SDK.
• Unknown data flows. Companies that build in analytics or advertising SDKs without knowing their data transmission take on data protection risks.
• SDK developed separately from the product. If the SDK does not keep pace with the interface, new functions are missing and customers switch to their own integrations.

Frequently asked questions

Does every software company need its own SDK?

No. An SDK is worthwhile if developers are the target group or customers build the service into their own software. For products operated exclusively through a user interface, the maintenance effort is seldom proportionate to the benefit.

Can SDKs be generated automatically?

Partly. From a machine-readable interface description, SDKs for several languages can be largely generated automatically. This reduces the maintenance effort, but the result is often less convenient than a hand-crafted SDK.

How can the quality of an SDK be measured?

The most telling measure is the time from first opening the documentation to the first successful request. Support requests per integration and the share of customers on current versions also count.

May a customer continue to use an SDK after the contract ends?

That is governed solely by the licence terms. Some SDK licences end with the service contract; others grant an unlimited right of use to the delivered version. This matters economically above all for SDKs that also work without the provider's interface.

The Roemer Capital view

For clients whose growth rests on integrations, the number of active integrations per customer belongs in the financial model and in the equity story. The equity story is the economic case put to investors and buyers for their entry into the company. The figure demonstrates switching costs better than any description of the technology.

Before a sale process begins, Roemer Capital clarifies with the client whether a software bill of materials exists for every SDK delivered and how many customers still work on outdated versions. Neither can be changed quickly. If the figures are available early, the client's law firm can align warranties and disclosures in the purchase agreement with them instead of reworking them under time pressure.