The IoT Library I Wish Existed When I Was Wiring Up My First 20 Sensors

"It's basically the library that I needed. Otherwise I would have to develop it from scratch."

That sentence is the punchline of a six-month decision a co-founder of a medical device company made. He is the technical co-founder of a startup building a multi-module neonatal incubator. He had three real options on the table. He could have hired a co-op student to write the integration plumbing. He could have written it himself, which he had already started doing. Or he could pick something off the shelf and pin it to his code.

He picked the third option. Not a platform. A library. And when I asked him later how he describes that choice to his board, he said the line above. It is the cleanest articulation I have ever heard of what hardware founders actually want when they are wiring up their first twenty sensors and looking at the wall of work in front of them.

This post is about why that distinction, platform versus library, matters more than IoT vendors think it does.

Platform vs library, defined

A platform is a system you adopt. You learn its dashboard, its concepts, its abstractions. You sign up, you provision a tenant, you read the docs to understand how their world is shaped, and then you bend your product to fit inside it. You give up control to gain features. The vendor is doing real work for you (running the cloud, scaling the backend, on-call rotation), and in exchange you accept their model of the world. You sign a contract.

A library is code you import. You pin a version. You read the source if something breaks. You compose it with the rest of your stack on your terms. The library has opinions but it does not have a worldview you have to adopt. Your product still looks like your product. The library is a load-bearing dependency, not a host environment.

Both shapes are legitimate. I want to be clear about that, because it is easy to strawman platforms and I am not interested in doing that here. Platforms have real strengths. If you are a non-technical founder with a hardware product and you need a managed cloud yesterday, a platform is probably the right call. They run the infrastructure. They handle scale. They give you a vendor to call when things break. For some founders, that trade is exactly right.

But for technical founders building hardware, it is usually the wrong shape. Not always. Usually. And the reason has nothing to do with features and everything to do with how builders actually think.

Why builders default to library thinking

Watch what a builder does when they hit a new problem. They open their package manager. They search for the closest existing solution. They install it. They read just enough source to understand what it does. They wire it into their code. They keep going.

That is the default move. It is the move because it preserves something builders care about more than they care about features: composition. A builder wants to compose pieces. They want to read source when they need to. They want to ship a product, not adopt a vendor.

When a hardware founder evaluates IoT options, the decision frame is almost never "platform A versus platform B." It is "build vs hire vs use a library." Those are the three boxes. The Salim quote earlier about hiring a co-op student to write a custom solution lands here exactly. The mental model is: I have an integration problem, and the question is who solves it and how do I keep control of the result.

That framing is invisible to a lot of IoT vendors because they sell into procurement, not into engineering teams. The deck pitches managed scale and an SLA. The engineer evaluating the deck is asking, can I pip install this and read the source on a flight. Those are different conversations.

When the founder I quoted earlier said he wanted to "download and pin to my code and then use it within the system internally," he was describing the builder mental model in plain language. Not a system to adopt. Code to compose.

What an IoT library should actually include

If we take the library shape seriously, here is the concrete surface area it should cover. This is the stuff every hardware team ends up writing, and it is the stuff that should already exist as code you import.

Protocol adapters. BLE, MQTT, Modbus, CoAP, HTTP, the long tail. One of the harder lessons from the customer interview I quoted: "Each machine has their own protocol. So not only languages, but even like system architecture." If you are integrating ten device families you are dealing with ten quirks. A library that ships solid adapters for the common protocols saves you weeks per integration. Platform thinking gets this wrong by trying to hide protocols behind a generic ingestion endpoint, which works until your one device that speaks broken Modbus shows up.

Device identity and certificate management as a code-level primitive. Not a vendor portal. A library should expose enrollment, rotation, and revocation as functions you call. The certs live on disk where you decide. The cloud-side check is a verifiable signature, not a magic API key tied to your account.

Data pipeline primitives. Payload validation, batching, retries, backpressure, offline buffering. These are the load-bearing pieces of any telemetry path and every team writes them. They should be in the box.

An update mechanism. OTA should not be a separate product you integrate. It should be code you compose, with the same primitives and the same logger as the rest of your stack. You decide when to roll, where the artifact lives, what triggers a rollback.

Observability hooks that fit your existing logger. Not a vendor dashboard. Not a vendor metrics format. Hooks that emit structured events into your tracer of choice and your log pipeline of choice.

A permissive license. Apache or MIT. Legal review takes an afternoon, not a quarter. If your library has a custom license you are signaling that you want to be a platform.

For each of these, the platform version of the same idea is fine. It is just a different shape. MQTT-as-a-service vs. an MQTT client you import. OTA-as-a-product vs. OTA-as-code. Identity-in-a-portal vs. identity-as-functions. Same problem, different ergonomics, different control surface.

What an IoT library should NOT include

The negative space matters more than people think. A library overreaches when it tries to be everything, and the second it does that, it starts behaving like a platform with extra steps.

A web dashboard. Build that yourself. Use Grafana. Use whatever. Not the library's job. The moment your IoT library ships a hosted dashboard, you are now coupled to the vendor's UI roadmap.

A billing system. If the library has billing, it has tenants. If it has tenants, it has a contract.

A team management UI. RBAC primitives are fine. A "manage your org" UI is a platform feature.

Vendor lock-in to a specific cloud. If the library only runs on the vendor's cloud, it is not a library. It is a client SDK to their platform, which is a different thing.

Required telephone-home opt-outs. Phoning home by default is platform behavior. A library runs where you put it.

I am being concrete here because the slope is slippery. Lots of things that started as libraries quietly turned into platforms by accreting these features. The way you keep a library a library is by being disciplined about what you say no to.

The tradeoff: who carries the ops burden

Honest answer time. The library shape costs you something. With a platform, the vendor runs the cloud. They pay for the on-call rotation. They get woken up at 3 AM. With a library, that is your team. You run the cloud. You take the page. You patch the CVE.

The founder I quoted runs his own cloud. He still does. What he stopped doing was writing the integration code that connects his devices to his cloud. That was the trade he was willing to make: keep ownership of the infrastructure, outsource the plumbing.

Many founders are not willing to make that trade, and they shouldn't. If you do not have a backend engineer on your team and you are not planning to hire one, buy a platform. Seriously. The library shape is for teams that already have, or already plan to have, the people to run their own backend. It is for teams who would rather control the stack and pay the ops cost than save the ops cost and lose the control. There is no shame in either choice. They are different shapes for different teams.

What is wasteful is when a team that wants the library shape ends up paying for a platform because the library shape was not on the menu. They get billed for managed cloud they do not need, locked into a UI they do not use, and forced into an abstraction model that does not match how they think. That is the gap I care about.

A founder, in his own words

"It's basically the library that I needed. Otherwise I would have to develop it from scratch."

(Co-founder of a medical device startup, post-purchase debrief)

That is the whole pitch. Not "the platform that scaled my business." Not "the dashboard that gave me visibility." The library I needed, otherwise I would have written it from scratch. Six months of evaluation collapsed into one sentence.

Why most IoT vendors get this wrong

Without naming names, here is the structural reason most IoT vendors sell platforms. The economics of the business model favor it. Platforms have higher contract values, longer sales cycles, more predictable expansion revenue, and a cleaner story for enterprise procurement. The sales motion is built around it. The pricing page is built around it. The investor deck is built around it. Once a company is structured to sell a platform, it is genuinely hard to also ship something that looks like pip install thing.

That is not a moral failing. It is just what the incentives produce. And the result is that there is a real category gap for builders who want library-shaped tools. The platform vendors do not serve them, the open-source projects are usually fragments rather than a coherent surface, and so the founder ends up writing the integration code themselves. Which brings us back to the co-op-student decision.

We built SCADABLE around library-first principles. There is a cloud platform behind it (someone has to run the broker, the audit log, the time-series store), but you interact with it via an SDK you pin to your code. The way you think about it is: my product is my product, and SCADABLE is a dependency. Not a host. Not a tenant. A dependency.

pip install scadable

import scadable as sc
 
dev = sc.Device(id="incubator-7", project="corvita")
dev.telemetry.emit({"temp_c": 36.8, "spo2": 0.97})
dev.ota.subscribe(channel="stable")

That is the shape. Read it, pin it, ship it. If you want to know what dev.telemetry.emit does, the source is right there. If you want to swap the transport, the transport is a parameter. Your code stays your code.

If you are at the build-vs-buy moment

If you are a technical co-founder or a solo embedded engineer wiring up your first twenty sensors, and you are at the moment of deciding whether to build the integration layer yourself, hire someone to build it, or use something off the shelf, that is exactly the conversation we are good at. We run 30-minute architecture reviews for hardware founders facing that call. We will look at your stack, your protocol mix, your device count, your scale targets, and the team you have today, and we will tell you honestly what fits. Sometimes the answer is a library. Sometimes the answer is a platform. Sometimes the answer is "you have already written half of this, finish it." We are not trying to win every conversation. We are trying to be the people you trust at this exact decision point. Book a slot at https://cal.com/rahbaral/quick-chat.