Hardware teams shouldn't have to become IoT experts to ship a connected product

Every team building a connected hardware product hits the same six walls, in the same order, and they spend the same eight to fourteen months hitting them.

The first wall is a protocol mismatch. The device speaks Modbus, or BLE, or some proprietary frame the manufacturer published in a 1998 PDF, and the cloud expects MQTT or HTTP. The second wall is security. The auditor wants mTLS with rotation, the CISO wants per-device identity, and AWS IoT has a tutorial that gets you 60% of the way there before it stops scaling. The third wall is fleet management. You shipped 200 devices, half of them are behind NAT, and you cannot SSH into any of them. The fourth wall is OTA. You need to update firmware safely, with rollback, without bricking a unit in a hospital basement. The fifth wall is observability. Something is wrong on Line 3 and the only signal you have is that the dashboard went stale six hours ago. The sixth wall is the regulator, who arrived late, looked at all of this, and asked for an audit log of every byte that ever crossed the boundary.

None of those walls have anything to do with the product the team is actually trying to ship. That is the part that is easy to lose sight of in the middle of it. The team did not start the company to write a Modbus state machine. They started it to ship a neonatal monitor, a smart inverter, a connected building HVAC controller, an asset tracker, a medical imaging device. The IoT layer is the toll they pay to ship the thing that mattered.

We have watched enough teams pay that toll to be tired on their behalf.

What the toll looks like

The dollar number on the toll is mostly hiring. A firmware engineer who can do all six walls is a $180k to $250k senior hire (we wrote about the actual loaded cost here), they take six months to onboard, and the work they do is mostly invisible until something breaks. Most early hardware teams cannot afford this hire and so they assign it to whoever has the most embedded experience on the team, which is usually one person, who burns out, ships the integration to 80% complete, and then either leaves or stops shipping the product.

The time number on the toll is months. We have seen teams lose a year to "just getting the data into the cloud." That year was not spent on the product. It was spent on a parallel project the customer never asked for and never sees.

The strategic number on the toll is enterprise lockout. The teams that ship the integration cleanly land enterprise pilots. The teams that don't sit at $50k MRR for two years while the procurement teams ask polite questions about audit logs. We documented the connected-product penalty in detail; the punchline is that the cost of getting IoT wrong scales with how big the customer you wanted to land was.

What we are building toward

SCADABLE is building toward a world where connected hardware companies stop having to care about IoT.

That sentence does most of the work. The implication is that the six walls become someone else's problem. Specifically, ours. You upload your device manual, you point at the gateway hardware you picked (Linux box, ESP32, whatever), and the system handles protocol translation, security, fleet management, OTA, observability, and the audit log automatically.

When something fails along the way, an engineer steps in and resolves it for you. That last sentence is the part that most "AI handles your IoT" pitches skip. It matters because the failure mode of an automated system is not "it works" or "it doesn't work." It is "it works most of the time, and the times it doesn't are unpredictable." We resolved that by putting humans in the loop, which we wrote about separately.

The mechanism for getting from "I have a device" to "live data is in my cloud" is a drag-and-drop. We walk through what actually happens between the two in a separate post on the onboarding pipeline. The short version: the device datasheet becomes a Python device class, which compiles to a YAML driver, which deploys to a gateway running our Rust runtime, which streams events to your cloud over an authenticated unified API. You see the result. The middle is ours.

The vision is simple

Hardware teams shouldn't have to become IoT experts to ship a connected product. They should be able to focus on the thing that matters: the product, the patient, the customer. The layer underneath should just work.

That is it. That is the whole pitch. Everything else SCADABLE does (the SDK, the gateway runtime, the AI-generated drivers, the verification layer, the engineer-in-the-loop fallback, the multi-protocol unified API) is mechanism in service of that vision. We are happy to argue about the mechanism. The vision itself is not up for debate.

What this means for our roadmap

If the vision is "stop having to care about IoT," then the product roadmap is whatever closes the gap between that and what we ship today.

Today, our customers still have to care about IoT a little. They have to upload the manual. They have to pick the gateway. They have to wire the cloud destination. The system handles everything in between, but those three actions are still on them.

The roadmap from here is collapsing those three actions one at a time. Manual upload becomes "we already have this device in our library, you just clicked it." Gateway selection becomes "tell us what your BoM target is, we tell you which gateway hits it." Cloud wiring becomes "we are already a first-class destination in your data warehouse." Each of those is its own product effort, and we will write about them as they ship.

The state we are aiming at is the customer thinks of SCADABLE the way they think of Stripe. They do not "use Stripe" in their daily work. They built their product, Stripe handles the money flow, and on a Tuesday they remember Stripe exists when they look at the dashboard. That is the relationship we want hardware companies to have with the layer underneath their connected product.

The shape of the answer

If your team is in the middle of any of the six walls right now, we are not going to pretend we have already collapsed all of them. We have collapsed protocol translation across 30+ industrial and commercial protocols. We have collapsed gateway runtime to a single image that runs on Linux and ESP32. We have collapsed the unified API to one endpoint that does not care which protocol the device speaks underneath. The verification layer and the audit log are shipped. OTA at fleet scale is in flight.

We are not done. The vision is the destination, the product is the partial implementation, and the engineer-in-the-loop is what bridges the two for now. If that sounds like an honest answer rather than a pitch, that is the company you are talking to.

If you want to see the partial implementation working, we put a live demo up that walks through the flow from device manual to streaming data. If you want to talk about whether the partial implementation maps to your specific situation, let us talk. The honest conversations are the ones we get the most out of.