Open this lesson in your favourite AI. It'll walk you through the why, explain the demo, and quiz you on the try-it list.
The instinct to 'make it smart' is usually wrong. Every wireless link you add to a device adds antennas, certifications, power draw, software complexity, security surface, and a class of failures (Wi-Fi down, captive portals, expired certs, IPv6 weirdness) that simply don't exist for a wired or standalone product. Before you commit, you must answer four questions: what data must move, in which direction, with what latency tolerance, and what happens when the link is down? If 'nothing happens' or 'the device buffers and uploads later' aren't acceptable, you have a much harder product to ship — possibly one that shouldn't be connected at all.
A decision framework for whether a feature should be online at all.
Use these three in order. Each builds on the one before.
In one paragraph, explain why being 'connected' has a real cost — listing the categories of cost a product team takes on by adding wireless to a previously offline device.
Walk me through what physically happens between an app tap and a light bulb turning on, when both are on the same Wi-Fi but the command routes through a cloud broker rather than a local LAN call.
Given a fitness ring that must store 7 days of biometric data offline, sync only when the user opens the companion app, and never drain more than 5% of its tiny battery per day — what storage strategy on-device, and what sync protocol off-device, would you pick?
For every feature you're tempted to put 'in the cloud', answer ALL FOUR:
1. WHAT DATA MOVES?
a. Sensor telemetry (low-volume, append-only)?
b. Commands (low-volume, real-time)?
c. Media (video, audio — high bandwidth)?
d. Software updates (occasional, large)?
2. WHICH DIRECTION?
• Uplink only (device → cloud)? Easy. MQTT publish, batched HTTPS.
• Downlink only (cloud → device)? Need a persistent connection or polling.
• Bidirectional with real-time? Hard. WebSocket / MQTT subscribe.
3. WHAT LATENCY IS ACCEPTABLE?
< 50 ms — control loops, AR/VR, gaming. Use wired or local network.
< 500 ms — voice commands, dashboards. Wi-Fi / cellular fine.
< 5 s — most consumer IoT (light switch responds slowly = bad UX).
minutes-hours — telemetry, weather stations, soil monitors.
days — cattle tags, GPS trackers on shipping containers.
4. WHAT HAPPENS WHEN THE LINK IS DOWN?
a. Acceptable: device buffers locally, uploads on reconnect.
Required: local NVS/flash for the buffer; backoff and resume code.
b. Acceptable: feature degrades but device still functions.
Required: local fallback logic. Hardest path to test.
c. Not acceptable: feature simply doesn't work.
Required: you may not have an IoT problem — you have a connectivity problem.
Re-think whether the connection should exist at all.
A LIGHTBULB EXAMPLE
───────────────────
"Smart" lightbulb: turn on via app.
Latency: < 1 s. Bandwidth: tiny. Direction: downlink.
Offline: if my Wi-Fi is down, can I still flip the wall switch?
If NO, you've made the customer's house worse than dumb bulbs.
If YES, the connectivity is purely additive — ship it.