And what a time that was. You didn’t just use an SDK—you embraced it. An SDK (Software Development Kit) didn’t just give you functionality; it gave you a personality test. If you survived the setup, the documentation (printed, of course), and the linking process, you came out stronger. It was like joining a secret club where the entry fee was patience and a willingness to suffer through compiler errors.
Once you figured it out, though, it was magic. You’d unpack the lib files, link the headers, and finally, you’d compile your code with your dependencies locked in, sitting snugly alongside your application. If you were on Windows, your code shipped with those .dll files you needed, tucked neatly in the same folder as your executable, like a kid bringing their lunch box to school. On Linux? You could go fully self-contained with a trusty -static flag in gcc, bundling everything into a single binary. No surprises, no “we’ve updated the API” emails, just you and your rock-solid executable.
Then came web APIs. At first, they felt like the future. While SDKs let you integrate libraries directly into your project, APIs took things a step further. They let you interact with services over the network—no linking libraries, no setting up headers. Just a URL and a key. Need payments? Stripe. Need maps? Google Maps API. Need SMS or VoIP? Twilio. It was like ordering takeout instead of cooking: fast, convenient, and so much easier than sweating over the SDK stove.
But here’s the thing about APIs: they don’t live in your code. They live out there, on someone else’s system, with someone else’s rules. And when they change—because they always do—it’s like coming home to find your roommate has replaced your kitchen with a juice bar. Sure, it might be trendy, but where the hell is your coffee machine?
I remember working with Asterisk for VoIP and Kannel for SMS. Asterisk was like a grumpy old mechanic: temperamental, but once you understood it, it could do anything. Kannel? That was like the moody artist friend who painted you a masterpiece but wouldn’t tell you how to hang it on the wall. It wasn’t easy, but once you got it running, it was stable. If something broke, it was your mess, and you could fix it.
Compare that to Twilio. It’s brilliant—don’t get me wrong—but if Twilio sneezes, your app catches a cold. And if they update their API, you’re suddenly rewriting code at 3 a.m., muttering curses at their changelog, and praying the users don’t notice anything by sunrise. That said, if Twilio were to make such a change, I’d trust they’d do it responsibly: clear documentation, proper timelines, and plenty of warning. But still, 3 a.m. is 3 a.m., and I’ve been there enough to know it’s not where you want to be.
APIs are like Lego blocks. You can build incredible things with them, but you’re stuck with the pieces someone else decided you needed. Want a custom piece? Too bad.
Back in the SDK days, you owned your stack. You understood how things worked under the hood. Your bugs were your bugs, and your dependencies were compiled, predictable, and wouldn’t up and leave you for a version 2.0 without your approval. Sure, it sometimes felt like grilling your own burger from scratch—grinding the meat, shaping the patty, and lighting the grill—but at least you knew exactly what went into it, and it tasted the way you wanted.
Now, don’t get me wrong: I love APIs. They’ve shaped modern software development and unlocked incredible innovation. But I can’t help wondering if we’ve leaned on them too much. Are we building things better now, or just faster? And what happens when faster isn’t enough anymore—when inefficiencies pile up, when new threats emerge, and when we find ourselves tangled in dependencies we no longer control? The future is coming fast, and I can’t shake the feeling that we might not be ready for what it brings.