When most IoT projects fail, it’s not hardware issues - it’s faulty software architecture - ignoring the fact that physical devices have inconsistent connectivity, noisy data, scale problems, and operational complexity completely alien to web apps. Here’s what I encounter constantly.
1. - Think IoT Devices Are Reliable HTTP Clients (By far the most frequent mistake!)
Web devs write backends, assuming input requests come in, get processed, and output responses go out. That’s not how IoT devices operate! They have drop-offs. They become unavailable for hours on end. Sometimes, they’ll hop back in the middle of a conversation. Even duplicates become the norm! If you structure your backend for guaranteed, stateless, HTTP communication from your devices, you’re essentially signing up to lose data.
The fix: Jump to MQTT! Embrace persistent sessions with a Quality of Service (QoS) level 1. Design a local buffer for your devices to hang onto their data while the network’s taking a break. Make sure every server endpoint handles duplicate events as if it’s just seeing one (think idempotency!).
2. - Hit the database every time an IoT event fires (Performance killer)
If you’ve got ten devices chirping every 30 seconds, hitting the DB for each isn’t a big deal. Now, imagine 1,000 devices reporting every 10 seconds. You’re staring at 100 writes per second! Go to 10,000 devices, and your database will be out before you even know you have a problem.
The fix: Pipe everything through a message queue like Kafka or RabbitMQ first. Then, batched writes to your database (about 500-1,000 per write) will be far more efficient. Use Redis to hold real-time states for your dashboards. That way, they don’t bottleneck your DB writes.
3. - No strategy for gaps and outdated data (The creeping bug)
What happens when a GPS tracker drives through a tunnel? Your dashboard freezes. An hour later, it reconnects, and all its data floods in at once. If you don’t plan for these gaps, your system will show either old data as fresh or present a messy rush of events out of order on re-entry.
The fix: The key is to have devices timestamp their own data - not your server. Maintain a “last seen” status for each device, marking positions as old after a certain timeout. Display that old data clearly in the UI, perhaps with a different icon colour or a “last seen X minutes ago” indicator.
4. - No filter or smoothing for raw sensor data (The noisy beast)
Raw data from sensors is rarely perfect. That GPS reading could be fifty meters off, even if the device is sitting still. Your RSSI could be bouncing ten dBm around. Sending raw data to your alert system will cause constant false positives.
The fix: Utilise a Kalman filter or a rolling average for your RSSI and GPS data. For your alerts, implement a debounce mechanism - only trigger if the data crosses a threshold for a defined number of consecutive readings, not just a single instance.
5. - Overlooking the OTA update (The ongoing operational headache)
You push out 500 devices. Three weeks down the line, a major bug pops up. Unless you have a plan for Over-the-Air (OTA) firmware updates, your options are a time-consuming manual trip to each device or learning to live with the bug - neither of which is a sustainable option.
The fix: Design for OTA from day one! Implement a dual-partition (A/B) architecture, hash verifications (SHA-256), cryptographic signatures, post-boot integrity checks with automatic rollbacks, and staged rollouts (start with 1%, then 10%, etc.).
6. - Ignoring security because "it's internal" (The high-risk bet)
Running MQTT on port 1883, skipping authentication, and having no TLS, just common passwords… this might seem acceptable during development, but in production, it opens the door to anyone reaching your broker to send bogus location data or peek at your entire asset feed.
The fix: Upgrade to MQTTS (port 8883), TLS 1.3, and employ mutual TLS (mTLS) with individual certificates for each device. Use topic ACLs to ensure each device can only send data to its specific channel. It’s a minimum requirement for anything beyond a toy project.
7. - Reinventing the wheel when platforms already exist (The time sinkhole)
The MQTT broker, device registry, OTA infrastructure, digital twin model, geofencing, alerting engine, dashboards - building all of this from the ground up consumes months of development before you’ve even written a line of product code. This is where a lot of IoT projects get stuck.
The fix: Distinguish between commodities and differentiators. Your ingestion pipeline and device management are commodities; leverage a managed platform. Your geofence logic, alerting rules, and business workflows - that's your product. Build that. Buy the rest.
The bottom line
Every single one of these mistakes is a result of taking assumptions from web development into a realm where they simply don’t hold true. IoT devices aren’t web browsers. The network isn’t always up.
The data isn’t always clean.
Be ready for the unexpected from day one. You’ll thank yourself later. AssetTrackPro was engineered with these lessons in mind, offering a robust ingestion pipeline, OTA management, mTLS security, and a production-grade geofencing engine as a platform solution.
Top comments (0)