IoT survival guide - Rules of the Road
- hello593537
- 2 days ago
- 6 min read
Practical strategies The IoT landscape is evolving fast.
LTE is being phased out, AI is reshaping both opportunity and risk, and threats are growing more sophisticated—all while IT teams stay lean and device counts climb into the tens of billions.
How to build connected products that will still make sense ten years from now
The Internet of Things was supposed to make everything simpler.
Instead, we connected millions of devices to clouds, gateways, apps, subscriptions and proprietary ecosystems — and discovered that every additional connection creates another dependency.
The next phase of IoT will be different.
The winners will not necessarily be the products with the most features, the biggest cloud platform or the cleverest app. They will be the products that continue to work when something else doesn't.
That is the starting point for the Tigertek IoT Survival Guide.

Rule 1: The device must do something useful without the Internet
Ask the simplest possible question:
What happens when the Internet disappears?
If the answer is “the product stops working”, you have designed an Internet-dependent product rather than a resilient IoT product.
For many applications — energy, HVAC, pressure, temperature, industrial monitoring, buildings and infrastructure — the fundamental measurement and control functions should remain local.
A sensor should still sense.
A display should still display.
An alarm should still alarm.
A controller should still control.
Connectivity should enhance the product rather than define its ability to function.
This principle is becoming increasingly important as connected devices move from consumer convenience into critical physical systems.
Rule 2: Local first. Cloud second.
For years the default IoT architecture has been:
Sensor → Gateway → Internet → Cloud → App → User
But there is another architecture:
Sensor → Local Interface → User
with cloud connectivity added only where it creates genuine value.
This sounds almost too simple.
That is precisely its attraction.
Local processing and display can reduce latency, infrastructure, cybersecurity exposure, installation complexity and continuing operating costs.
The cloud remains extremely useful for fleet management, remote diagnostics, historical analysis, AI and enterprise reporting.
But it does not have to sit in the middle of every interaction.
The emerging principle is therefore not “no cloud”.
It is:
Cloud where useful. Local where essential.
Rule 3: Avoid protocol religion
Bluetooth. BLE. Wi-Fi. LoRaWAN. Zigbee. Thread. Matter. Modbus. BACnet. M-Bus. MQTT.
Which one wins?
Probably none of them.
Industrial and building environments are already heterogeneous and are likely to remain so.
A manufacturer betting everything on one communications technology risks designing obsolescence into the product.
A better philosophy is to separate the physical measurement from the communications layer.
Think:
Sensor → Intelligence → Translation → Network
rather than:
Sensor → One proprietary ecosystem
Increasingly, the valuable device may not be the sensor itself.
It may be the bridge between sensors and systems.
Rule 4: Build bridges, not islands
There are already billions of perfectly serviceable machines, meters, pumps, boilers, compressors, heat pumps, solar inverters, industrial instruments and building systems in the world.
They are not all going to be replaced.
That creates an enormous IoT opportunity.
Instead of asking:
“How do we replace this equipment with something smart?”
ask:
“How do we make the equipment already installed smarter?”
A relatively inexpensive interface capable of reading existing equipment and translating its information into useful local and networked data can potentially unlock decades of installed infrastructure.
This is where IoT becomes less about gadgets and more about interoperability.
Rule 5: Treat energy as part of the communications architecture
For battery-powered IoT devices, energy is not merely a hardware specification.
It determines the entire architecture.
Every transmission costs energy.
Every unnecessary wake cycle costs energy.
Every processor operation costs energy.
Every additional network dependency potentially costs energy.
A device capable of operating for five or ten years from a battery is fundamentally different from one requiring maintenance every few months.
Good IoT engineering therefore asks:
Does this data actually need to be transmitted?
Perhaps the edge device can analyse hundreds of readings locally and transmit only a change, alarm, exception or summary.
The cheapest packet may be the one you never transmit.
Rule 6: Edge intelligence changes everything
The traditional IoT device collected information.
The next generation will increasingly interpret it.
Instead of transmitting:
Pressure = 3.71 bar
an intelligent edge device might determine:
Pressure has fallen outside its normal operating envelope and the rate of decline indicates a probable system fault.
That is a significant transition.
IoT moves from:
measurement → transmission
towards:
measurement → interpretation → decision → transmission when necessary
As processors become smaller, cheaper and more energy-efficient, increasingly sophisticated analytics — and eventually specialised AI — can operate at the edge.
This reduces bandwidth and latency while potentially improving privacy and resilience.
Rule 7: Cybersecurity is now a product feature
Security can no longer be something added shortly before launch.
Every unnecessary Internet connection creates another potential attack surface.
Every default password, forgotten server, unsupported app and obsolete cloud API can become tomorrow's vulnerability.
Modern IoT therefore needs security designed into its architecture:
secure boot and firmware
authenticated communications
controlled software updates
encrypted data where appropriate
minimal exposed services
clearly defined support lifetimes
sensible data retention
local operation when remote services are unavailable
European cybersecurity regulation is also steadily turning these principles from good engineering practice into commercial requirements.
Security is becoming part of the product specification.
Rule 8: Design for the day the cloud company disappears
IoT products can easily outlive the software companies supporting them.
A mechanical pressure gauge may operate for decades.
An industrial transmitter may remain installed for fifteen or twenty years.
But what happens to a connected device when its cloud service closes?
Or its mobile app is discontinued?
Or an API changes?
Or the manufacturer stops supporting it?
This is an increasingly important purchasing consideration.
A resilient product should degrade gracefully.
Ideally:
The cloud can disappear and the core product still works.
That may become one of the most valuable promises an IoT manufacturer can make.
Rule 9: Give the customer ownership of their data
There is growing resistance to products that require users to send operational data to somebody else's server simply to see what their own equipment is doing.
This is particularly relevant in industrial, energy and building applications.
Local-first architecture offers an alternative:
Your equipment.Your network.Your data.
Cloud services can then become an optional layer providing additional value rather than a compulsory toll booth between the customer and their own information.
Open interfaces and documented protocols can make products more attractive rather than less defensible, because the commercial value moves into reliability, engineering, interoperability and trusted hardware.
Rule 10: Make installation boring
One of the most underestimated barriers to IoT adoption is installation.
If connecting a £150 sensor requires an engineer, gateway, IT department, cloud account, firewall configuration, annual subscription and a forty-page manual, the technology has probably defeated its own purpose.
The ultimate IoT interface may therefore be surprisingly mundane:
Connect. Power. Discover. Display. Done.
Complexity can exist inside the product.
It should not necessarily be transferred to the customer.
Rule 11: Don't connect something merely because you can
Perhaps the most important rule.
For every proposed connection, ask:
What value does this connection create?
If a local display solves the problem, use a local display.
If Bluetooth solves it, perhaps Wi-Fi isn't required.
If a low-power radio can operate for ten years, don't automatically install mains power.
If an existing Modbus connection already exposes the information, don't add another sensor.
If information never needs to leave the building, don't automatically send it to a server hundreds of miles away.
Good IoT architecture is increasingly about removing unnecessary technology, not adding more of it.
The IoT product that survives
Put these principles together and an interesting picture emerges.
The resilient IoT product of the future may be:
multi-protocol, locally intelligent, locally visible, energy-efficient, cyber-secure, interoperable and cloud-optional.
It can connect old equipment to new systems.
It can translate between protocols.
It can make decisions at the edge.
It can expose information locally.
And where cloud connectivity creates genuine additional value, it can connect upwards into enterprise systems, analytics platforms and AI.
That architecture is useful in factories.
It is useful in commercial buildings.
It is useful in energy management.
It is useful in HVAC.
It is useful in heat pumps and renewable-energy systems.
And increasingly, it is useful in the home.
The future of IoT may therefore be less about putting everything on the Internet.
It may be about giving every physical device the intelligence to decide when the Internet is actually necessary.
At Tigertek, we believe that distinction matters.
Because the best connected product isn't the one with the most connections.
It's the one that survives when those connections fail.
Tigertek — connecting the physical world intelligently.



