Why I published four SDKs for one small product

Norbelys has official SDKs for TypeScript, Python, Ruby and Go. There are three of us, and only one works on developer tooling full time. On any reasonable prioritisation exercise this is indefensible: four client libraries to maintain, four release processes, four sets of issues, for a product whose users could all fit in a room.

We did it anyway, and I would argue for it again. The reasoning is not “developer experience”.

An API without a client is an API most teams will not adopt

The people most likely to run cold email at real volume are the ones who want it inside their own systems — their CRM sync, their onboarding flow, their internal tooling. That is the whole premise: honest analytics and protected deliverability matter most when sending is programmatic and continuous, not when someone is clicking send in a dashboard.

Those teams evaluate an API by opening the docs and asking one question: how long until this is working in my stack?

“Here is a REST reference, write a client” is a real answer. It is also a decision point, and decision points are where evaluations die. npm install is not a decision point.

The SDK is not a convenience layer on top of the product. For the segment that matters most, it is the product’s first surface.

Four languages is a forcing function on the API itself

This is the part I did not expect.

Writing the same client four times, in four languages with genuinely different idioms, surfaces every place where the API is arbitrary. Something that feels natural in TypeScript can be graceless in Go. A pattern that is idiomatic in Ruby can be impossible to express cleanly in Python without a wrapper nobody wants.

Every time an SDK needed a hack to feel native, the hack was pointing at a flaw in the API, not in the language. Loose typing, inconsistent pluralisation, an endpoint that returned different shapes depending on a flag, pagination that worked one way here and another way there.

The API changed roughly a dozen times because a client library was awkward to write. Every one of those fixes made the raw HTTP interface better for people who never touch an SDK at all. Four implementations is the cheapest API review I have ever run.

It is less work than it looks, if you decide that up front

The cost is only bearable because the surface is generated from one source of truth and the clients are thin. They handle auth, retries, pagination and typing. They do not contain product logic, because product logic in four places is where this becomes the disaster everyone predicts.

The rule: if a behaviour has to be implemented in each SDK, it belongs on the server instead. Every time that rule gets broken, it gets paid for four times.

The fifth client

The MCP server is the same argument taken one step further. The clients that matter now are not only human developers in four languages — they are agents, and an agent needs the interface described accurately more than it needs a library.

Same principle either way. Meet the caller where it already is, and let the shape of what they need tell you what is wrong with your API.