A vendor's ready-made code package that saves you from calling their API by hand.
Why it exists
Calling a service's raw API means every team rewrites the same request building, auth, and error handling, and gets the details subtly wrong. That repetition is waste and a source of bugs. An SDK exists as a ready-made library in your language that wraps the API, so common calls are a function away instead of hand-built each time.
How it actually works
Instead of crafting raw API requests, you install the vendor's SDK, a library that wraps their API in convenient functions. "Charge this card" becomes one line instead of a hand-built request.
SDKs speed up integration and reduce mistakes, at the cost of another dependency to keep updated.
A senior PM walks you through it
A junior PM, stuck
In vendor scoping the engineer said integrating the payment gateway takes about two days with their SDK, versus about two weeks building against the raw API. I wrote that down to repeat to my lead, but I cannot actually explain where the difference comes from, and if he asks "two weeks of what?" I have nothing. I do not want to quote a number I cannot defend.
An SDK is the vendor's own prewritten version of the code your team would otherwise hand-build to call their API, so the saving is real work that moves from your side to theirs. There is a two-minute way to see exactly what it takes off your plate, and the team already has it: the pull request where they swapped hand-built code for the SDK. This is that PR, trimmed to the two sides of the change. Read it once, then take the steps with me.
PR #212: use the gateway SDK for the checkout charge
Removed: hand-built gateway call (38 lines)
- const res = await fetch('https://api.gateway.test/v1/charges', {
+ // auth, retries, backoff, and timeouts now live inside the SDK
Review
Rafi: the SDK now owns retries and backoff, so we delete our own loop. Approved.
Click a step to see the lines it points at.
Mistakes I've seen
Repeating "two days instead of two weeks" upward without knowing what the weeks covered. When your lead asks what the SDK actually saves, "retries, auth, and error mapping we no longer maintain" is an answer; a shrug is not.
Treating an SDK as free speed. It is a dependency you now have to keep updated and trust for security fixes, so the win comes with a standing cost, small but real.
Assuming an SDK covers your case because it exists. SDKs ship per language and platform, and one that is missing for your stack, or missing the one call you need, quietly puts the hand-built work back on the table.
Reading the diff as "they deleted a bunch of code" and stopping there. The deleted code is the point: it names exactly which chores the vendor took over, which is the whole basis of the estimate.
Tell your lead: "The SDK saves roughly two weeks because it ships the retry loop, auth, and error handling prewritten, so we do not build or maintain that code. The cost is one more dependency to keep updated, and it only helps if there is an SDK for our stack." You just turned a vendor's time claim into a defensible line by reading what the SDK actually owns.
Where a PM meets this
"They have an SDK" usually means faster integration, a small plus when comparing vendors.
SDKs exist per language/platform; a vendor with no SDK for your stack means more manual work.
Hear it in a meeting
"Their SDK handles retries for us, so we don't have to build that."