IoT Meets Web: What I Learned Moving Between Hardware and Frontend
6 March 2026
I've spent the last few years as a Lead Software Engineer at Elemental Machines, building software for IoT systems — sensors, data pipelines, real-time dashboards, device management. Before that, and in parallel, I've been building web and mobile apps: this site, Barba Studio, client work through Honeyside.
Moving between these two worlds constantly has given me a perspective that working in only one of them wouldn't. They look like completely different disciplines. They're not.
The Web Assumes Abundance. IoT Doesn't.
The first thing IoT teaches you is that the web has been spoiling you.
On the web, you assume a fast, reliable connection. You assume the server is always up. You assume that if something fails, the user can just refresh. These assumptions are so deeply baked into how we build web apps that we don't notice them until they stop being true.
In IoT, nothing is reliable by default. A sensor might be on a cellular connection in a basement. It might go offline for six hours and come back. It might send 200 readings per second or go silent for a day with no warning. Your software has to assume failure is normal — not an edge case to handle gracefully, but the expected operating condition.
This changes how you think about data ingestion, error handling, and state. And once it changes, you can't un-see it on the web side. I now think differently about offline states, retry logic, and optimistic UI in web apps because I've had to think about them seriously in systems where getting it wrong means losing sensor data permanently.
Real-Time Is Harder Than It Looks
Both worlds care about real-time data, but the problems are different.
On the web, real-time usually means WebSockets or Server-Sent Events pushing updates to a browser. The hard part is UI — keeping state consistent, avoiding unnecessary re-renders, making the experience feel live without hammering the client.
In IoT, real-time means ingesting thousands of readings per second from hundreds of devices, routing them to the right consumers, and storing them efficiently. The industry has converged on tools like MQTT, message queues, and time-series databases. The hard part is infrastructure — throughput, ordering guarantees, backpressure.
The insight that transfers: both problems are fundamentally about event-driven architecture. The patterns — producers, consumers, queues, subscriptions — are the same. The scale and substrate differ. Learning to think in events on the IoT side made me a much better architect on the web side, and vice versa.
Deployment Is a Completely Different Problem
On the web, deploying a fix means pushing a commit. Your CI runs, your CDN updates, every user gets the new version the next time they load the page. It's so fast and frictionless that we sometimes push multiple times a day without thinking about it.
In IoT, the device is physical. It might be in a lab you don't have access to, or mounted inside a piece of equipment, or deployed in a facility across the country. An over-the-air firmware update that goes wrong can brick a device. Rolling back is not always possible. The "just push a fix" reflex that web development builds into you becomes genuinely dangerous.
This has made me more deliberate about deployments everywhere. Feature flags, staged rollouts, the discipline of asking "what does a bad deploy look like and how do we recover" — these feel optional on the web until you've worked somewhere they're not.
The Reliability Mindset
Hardware fails in ways software doesn't prepare you for. A sensor drifts out of calibration. A network switch drops packets asymmetrically. A device clock desynchronizes and starts timestamping readings in the past. These aren't bugs you can fix with a code change. They're properties of physical systems that your software has to accommodate.
The mindset this builds: defensive architecture by default. Don't trust the data. Validate at every boundary. Design for the system to be partially degraded at any given time and still produce useful output.
I've carried this into web development. APIs lie. Third-party services go down. Users do things you didn't anticipate. The IoT instinct to treat every input as potentially wrong until proven otherwise has caught more bugs in my web code than I'd like to admit.
What Each World Gets Wrong About the Other
Web developers who move into IoT tend to underestimate the hardware. They build beautiful dashboards and real-time UIs but design data pipelines like they're building a REST API — synchronous, stateless, optimistic. The first time a device floods the ingestion endpoint or drops offline mid-session, the assumptions collapse.
IoT engineers who move into web development tend to overengineer reliability. They add retry queues for operations that should just fail fast. They treat the browser like an unreliable embedded client and build accordingly. The result is software that's robust but slow to develop and hard to change.
The sweet spot is somewhere in the middle: web development's iteration speed and user-focus, IoT's discipline around failure modes and data integrity. Getting there requires having worked seriously in both.
The Skill That Transfers Best
If I had to name one skill that transfers perfectly between the two worlds, it's this: knowing where the boundaries are in your system and treating them with respect.
In IoT, the boundary is between your software and the physical world. At that boundary, all bets are off.
In web development, the boundary is between your code and everything outside it — user input, external APIs, the network, the browser. At that boundary, the same thing applies.
Everything inside the boundary, you can reason about and control. Everything outside it, you can only defend against. The engineers who understand this — regardless of which domain taught it to them — build better systems.
The opinions expressed here are my personal opinions. Content published here is not monitored or approved by Elemental Machines before it is posted and does not necessarily represent the views and opinions of Elemental Machines.