Software Development Kit

For a long time, borrowing a feature from another company meant reading a spec and writing the client code yourself. A team adding payments would get the documentation for an API — the agreed channel two programs use to exchange requests and responses — and build everything that talks to it from scratch.

The catch was that this code came out nearly identical at every company. Attach the endpoint, put the key in a header, retry a few seconds later when a request fails, convert the response into the language's own data types. Sixty pages of documentation and roughly 300 lines of code before the first payment went through, and the company next door wrote the same 300 lines again.

The provider lost on the deal too. Support kept fielding the same questions: how do I build the signature, how many times should I retry a failure, why does this field come back empty. After writing the same answer a hundred times, shipping that answer as code becomes cheaper than typing it again.

An SDK is that repeated 300 lines, written once by the provider and handed out as a package. The company adding the feature installs the bundle into their own product and calls a few functions. Instead of stopping at a published spec, the provider ships the code that uses the spec. The spec still exists underneath; the bundle just means nobody has to start from it.

It removes the waste of every customer writing the same integration from zero. Five things move inside the bundle.

1. Transport and authentication — which endpoint to hit, where the key belongs, and when an expired token gets refreshed all happen out of sight.
2. Retries and error handling — when the network drops or a request gets rejected for exceeding a rate limit, the delay and the retry count are already decided by people who know the service.
3. Type conversion — data going out and coming back arrives as objects the language handles naturally, so nobody writes string-parsing code by hand.
4. Device and platform differences — a bundle for a mobile app absorbs what differs between Android and iOS and exposes the same function names on both.
5. Diagnostics — a record of what was sent and what came back stays available, and bundles often ship alongside an error tracking feature that collects exceptions, groups them, and reports them upstream.

The payoff shows up as time. When sixty pages and 300 lines collapse into five lines, an integration takes half a day instead of three weeks. That gap decides deals: a team evaluating two payment providers will usually pick the one they got working before lunch. The provider gains as much. The same question stops piling up in support, and whole categories of misuse become impossible — writing a secret key into client-side code, for instance, can be blocked by how the bundle is shaped rather than warned about in a document nobody reads.

Three other routes reach the same feature. What decides between them is how much control the integrating team wants and how much time they can spend.

1. Call the API directly — write those 300 lines yourself. It's the slowest path, and it's the only one available when the provider doesn't publish a bundle for your language or when you need to change behavior the bundle decided for you.
2. Webhooks — the provider's server tells yours when something happened instead of waiting to be asked. If all you need is to know a payment completed, you open one address to receive it and install nothing.
3. Drop in a prebuilt screen — mount the provider's own interface inside a frame on your page. An hour of work, and almost no control over layout or wording. Teams often start here to confirm the feature gets used at all, then move to a bundle once it clearly matters.

The reasons for skipping an SDK nearly all trace back to one property: the bundle is installed inside someone else's product and runs there.

• Old versions persist. A change on the server reaches everyone the moment it deploys, but a bundle keeps running a two-year-old release until the customer updates it. That's why providers adopt something like semantic versioning, which signals the nature of a change in its version number, and postpone any breaking change that would stop existing code from working.
• You're a guest in someone's house. A heavy bundle makes their app larger and slower to start, and a crash inside your code reads to their users as their app crashing.
• Every language needs its own copy. Supporting JavaScript, Python, and Java means three things to build and three things to fix.

"With the SDK it's half a day. Wiring it up against the raw spec is closer to four."

Comparing integration cost to decide which route to take.

"Going from 3.2 to 4.0 changes how the calls are written. Let's notify customers before we ship it."

The release breaks existing code, so it needs warning ahead of time.

"That company is still on 2.1. The server has to keep accepting the old shape."

Customers remain on an old release, so both paths need support.

Pagedeck decided to ship a bundle that lets other companies embed its document editor inside their own screens. Sofia had brought back the same request from three enterprise accounts. Theo argued for supporting exactly three languages, and Mia agreed. With 45 people in the company, stretching to six languages means six copies to touch on every feature, and the bundle starts eating the pace of the main product.

The most common assumption is that shipping it once finishes the job. It looks like writing one set of code and publishing it. But nothing installed inside someone else's product can be recalled. As long as a customer sits on 2.1, the server keeps accepting both the old shape and the new one, and every supported release adds combinations to test. Three releases across three languages is nine things that can each break on their own. Ship without pricing that in and three years later you are holding up four releases at once.

The other misreading is that adding a language is cheap. Porting something that already works feels like a small surcharge. In practice each language carries its own examples, documentation, and test suite, and that whole set multiplies against every future change. A team supporting three languages that adds a fourth isn't taking on a quarter more work — it's taking on a third more work on everything it ships from then on. The cost lands in the future, which is exactly why it gets waved through in the meeting.