Every developer tool wants to live in your package.json. An SDK feels like a deeper integration, it gives the vendor a version number to talk about, and it is what the category expects. Most of the time, it is also the wrong shape for the job.
Avtrz does one thing: it returns a profile photo for a contact. The honest interface for “return an image” is a URL. So that is the whole product:
What an SDK actually costs
An SDK is not free just because installing it is. It adds weight to your bundle for a feature that renders one image. It adds a version you now have to track, and a changelog you have to read. It can break your build independently of your own code. And it ties a trivial capability to a dependency’s release schedule and a vendor’s decision to keep maintaining it.
“A dependency is a standing loan. You should only take one out when the thing you are buying is worth the interest.”
For a profile photo, it is not worth the interest. An <img> tag has been stable since before your framework existed. It will outlive your framework too. It works in React, in an email, in a server-rendered table, in an AI agent’s output, and in a no-code tool, without you porting anything.
When an SDK does earn its place
This is not an argument against SDKs. It is an argument for matching the interface to the job. An SDK earns its weight when there is real state to manage: auth handshakes, long-lived connections, retries, local caching, a streaming protocol. If the vendor is doing something genuinely stateful on your behalf, a library is the right tool.
Serving an image is not that. There is no session, no handshake, no protocol, just a request and a picture. When the job is that simple, the simplest interface is not a compromise. It is the correct answer, and it is the one that is still working in five years.
So before you add the next SDK, ask what state it manages. If the answer is “none,” you were probably looking for a URL.