Build, hire, or partner: the real cost of IoT infrastructure for hardware startups

Every hardware founder hits the same wall around month nine. The device works on the bench. A pilot customer wants ten units in the field. Suddenly the question stops being "does our sensor read accurately" and becomes "how do we ship firmware updates, prove who connected when, rotate certificates, and not get paged at 3am when a device drops offline."

That is the IoT infrastructure problem. And the build vs buy IoT decision around it is the most expensive call most hardware startups make in their first two years, because the wrong choice does not show up as a line item. It shows up as the product feature you did not ship, the embedded engineer who quit in month fourteen, or the AWS bill that grew faster than revenue.

This post is the framework I wish someone had handed me before I made that call. Three options, real numbers, and a set of questions to answer before your next board meeting.

The three paths, honestly

Before going deep, here is the shape of the decision. Most hardware companies pick one of these:

Path	Typical cash cost (year 1)	Time to first deploy	Lock-in risk	Maintenance burden	Best when
Build in-house	$200k to $500k loaded	9 to 18 months	None	High, forever	Cloud is your moat
Hire embedded + cloud	$180k to $250k loaded per hire	12 to 24 months (incl. hiring)	None	High, plus key-person risk	You found the unicorn
Partner with platform	$20k to $120k year 1	2 to 12 weeks	Medium to high	Low	Cloud is plumbing, not product

Numbers below are loaded comp (salary plus benefits, equity burn, hardware, software, tooling) for senior talent in major North American hubs. Adjust down 25 to 40 percent for remote-only or non-US hires. None of these numbers are precise to the dollar. They are the ranges I have seen across roughly two dozen hardware startups I have talked to in the last year, and they line up with public data from the 2025 Toronto Tech Salary Report and levels.fyi for senior embedded and infrastructure roles.

Option 1: Build in-house

This is the path most technical founders default to, because it feels like the safest option. You control the stack. No vendor can squeeze you. The IP stays yours.

Then you do the math.

A senior engineer who can credibly own an IoT backend (cloud, embedded, certs, OTA, observability) in Toronto, NYC, or SF runs $180k to $250k loaded. You usually need at least one and a half such people: one full-time owner, plus a fractional contributor from your firmware team to bridge the device side. Call it $300k to $400k of cash in year one for a competent two-person effort. In SF that number floats higher.

Then there is the opportunity cost, which is the line item nobody puts in the spreadsheet. If those two engineers were on product, what would they have shipped? For most hardware startups the answer is the next sensor, the next certification, the next customer-facing feature, in other words the actual reason customers buy. Pulling them onto cloud work delays that by 9 to 18 months. That is not a judgment call. That is what it takes to get fleet provisioning, OTA, audit logs, cert rotation, observability, and a usable device dashboard to production quality.

A common counterargument: "we will just use AWS IoT Core." This is a real and reasonable choice, and it is also the source of the most common surprise I see. AWS IoT Core gets you maybe 30 percent of the way there. You get an MQTT broker, basic device shadows, and rules. You still own:

• Fleet provisioning UX (the actual onboarding flow your installer uses on-site)
• OTA orchestration (rollback, A/B partitions, staged rollouts, signing)
• Cert lifecycle (issuance, rotation at 18 hours of a 24-hour cert, revocation)
• Audit logs that pass a SOC 2 or IEC 62304 review
• A device-facing dashboard your customers will actually use
• Multi-tenant project structure (because your customers have customers)
• Observability that distinguishes "device is offline" from "device is dead" from "broker dropped the connection"

Searches for "aws iot core alternatives" spike right around month ten of most hardware startups, and this is why. AWS IoT Core is a primitive, not a product. Treating it as the latter is the single most common reason I see budgets blow out.

If your cloud and device-management layer is genuinely your competitive moat (a ground-up new protocol, an unusual security model, something patentable in the platform itself) then build. Otherwise, you are spending product-team months on undifferentiated heavy lifting.

Option 2: Hire an embedded engineer with cloud experience

This sounds like the safe middle. You get a full-timer who owns it. You do not pay platform fees. You keep the IP.

The hiring market has other ideas.

Senior embedded engineers with real cloud experience are one of the harder profiles to fill in 2026. Anecdotally, time-to-fill for this exact role is running 3 to 6 months from open requisition to signed offer, with another 2 to 3 months of ramp before they are productive on your stack. So you are 5 to 9 months in before they ship anything, and you have already paid recruiting fees (15 to 25 percent of base, if you used an agency) and burned founder hours interviewing.

Then there is the single-point-of-failure problem. The canonical hardware-startup horror story goes: "our embedded guy quit and now nobody understands the OTA pipeline." I have heard versions of this from at least eight founders in the last year. When one person owns the entire device-to-cloud stack, their two-week notice can put your roadmap in a coma.

There is also a recruiting reality nobody talks about: the engineers who can actually do this job at the level your customers need are mostly already at well-funded scale-ups. The talent pool that is both available and credible at a Series Seed or Series A startup is small. Hardware founders routinely tell me they had three rounds of disappointing interviews before realizing the candidate pool just was not there.

Hire when: you have already shipped to dozens of customers, the role is genuinely full-time, and the hire will own a domain that is core to your differentiation. Do not hire when you are still pre-pilot and the real job is "ship faster."

Option 3: Partner with a platform

This is the path founders are most embarrassed to pick, which is funny, because it is the one that most often correlates with the companies that ship and survive.

The honest pitch for partnering: opex is predictable, time-to-first-deploy is measured in weeks not quarters, and you can put your engineering team back on the product. The honest tradeoffs: you pay a vendor, you take on some lock-in risk, and you give up some control over the deepest parts of the stack.

In an iot platform comparison, three categories matter:

1. Hyperscalers (AWS IoT Core, Azure IoT Hub, Google Cloud IoT, before it was killed). Powerful primitives, infinite scale, near-zero opinionation. You still build most of the product. Lock-in is real but mostly through habit and skill, not technology.

2. Traditional IoT platforms (Particle, Losant, ThingsBoard, the long tail). More opinionated, more done-for-you, but mostly designed in the 2015 to 2020 era when "IoT platform vs custom" meant choosing between a generic dashboard and a generic SDK. You write integration glue for every new sensor or protocol. The work compounds linearly with your device count.

3. AI-native platforms (the category SCADABLE sits in). The thesis is that the integration layer (drivers, protocol adapters, OTA flows, audit log schemas) is now generatable from a device manual, not a job to be done by a human. Upload the datasheet, get production-ready integration code, deploy. Lock-in is lower because the generated code lives in your repo, not in a vendor's runtime.

The interesting thing about partnering in 2026 is that "buy" used to mean "rent a closed platform." It now increasingly means "buy a code generator and own the output." That changes the lock-in math entirely.

Pricing on partner platforms varies wildly. Hyperscalers are usage-based and look cheap until you hit scale. Traditional platforms are seat or device-based and start at $1k to $10k per month for production usage. AI-native platforms are still finding their pricing; expect $20k to $120k for a year of production-grade usage at startup scale, all-in. That is one to two months of a senior hire's loaded comp, for a year of running infrastructure.

If you outsource iot development to a partner, the question to ask is not "how cheap" but "what do I own at the end." If the answer is "the code, the certs, the data, and a clear exit path," lock-in is manageable. If the answer is "a contract and a dashboard," you are renting your product.

A decision framework, in five questions

Forward this section to your CEO. If you can answer these honestly, the path picks itself.

1. Is the cloud and device-management layer part of your differentiation, or is it plumbing?

If a customer would pay more because of how your OTA pipeline works, build. If the customer pays for the device and the data and could not care less how the bytes get there, the cloud is plumbing. Plumbing should be bought, not built.

2. Do you have 12 months of runway you are willing to spend on undifferentiated infrastructure?

Not "do you have 12 months of runway." Are you willing to spend it here, instead of on the next sensor, the next certification, the next pilot? Most founders, when forced to answer this in front of their board, say no.

3. Is FDA, SOC 2, IEC 62304, or similar in your near future?

If yes, the audit log alone is a multi-month project. So is access control with proper trail. So is cert lifecycle with documented rotation. Partnering with a platform that has these baked in turns a 6-month compliance scramble into a 3-week vendor questionnaire. Building it yourself is fine, but budget the lawyer time and the auditor time, not just the engineering time.

4. What is your hiring market actually like?

Be brutally honest. If you have already tried to hire a senior embedded plus cloud engineer and got nowhere in 60 days, that is data. Stop and re-decide. The market is telling you something.

5. What is your exit strategy from each option?

Building in-house: you own the code, but the institutional knowledge lives in two heads. Hiring: same plus key-person risk. Partnering: depends entirely on the vendor. Ask, before signing: "if I leave you in 18 months, what do I take with me?" If the answer is not a clear list of artifacts (code, certs, data exports, schema), be careful.

So, should you build your own IoT backend?

If you have read this far and you are still asking "should I build my own IoT backend," the answer is almost certainly no, and that is fine. The hardware startups that win in 2026 are the ones that ship product, not the ones with the most elegantly engineered cloud. There are exceptions, and if you are one, you already know it.

For the rest, the realistic options are: rent the plumbing from a hyperscaler and accept that you still build a product on top, or partner with someone whose job is the plumbing so you can put your team back on the device.

We built SCADABLE because we kept watching hardware founders, our own first customer Corvita Biomedical among them, lose 9 to 18 months to a problem that, in 2026, an AI can do in an afternoon. Corvita is a neonatal medical device startup that needed to integrate six different sensor protocols on a deadline driven by FDA timelines, not engineering timelines. They uploaded the device manuals. The drivers, protocol adapters, OTA, and audit logs came back as production-ready code they own. They got their team back on the device. That is the bet: that the integration layer is generatable, the code stays yours, and the lock-in stays low.

If that fits your situation, talk to us. If not, the framework above still holds. Pick the path your runway, your team, and your differentiation actually point to. Not the one that feels safest in the moment.