How do you design an IoT device that works offline?

Most IoT products are built cloud-first. The device collects data, sends it up, and waits for instructions. That works in a demo on office Wi-Fi. It fails in a basement, a farm, a factory with a dead access point, or a city where the mobile network drops for an hour. Dependencies are debt, and the cloud is the biggest dependency a connected device has.

The core principle: local first, sync second

Ask one question about every function on your device: what should happen if the network vanishes right now?

• If the answer is "it keeps working", that logic belongs on the device.
• If the answer is "it can wait", that data goes into a queue.
• If the answer is "it can't work at all", challenge it. Most of the time, it can.

A thermostat should keep heating. A door lock should keep locking. A signage display should keep playing its schedule. Remote dashboards and analytics can catch up later.

Building blocks of an offline-first device

1. Local decision-making

Put control logic in firmware, with configuration that syncs down when available. Rules, schedules and thresholds live on the device. The cloud edits them. The device enforces them.

Our automated hydroponics system runs watering and nutrient dosing on local schedules and sensor thresholds. If the venue's Wi-Fi goes down, the plants don't notice.

2. A persistent store-and-forward queue

Readings and events go into a queue on non-volatile storage, not RAM. When the connection returns, the device drains the queue oldest-first.

Design choices that matter:

• Size the queue for the longest outage you'll accept, then decide what to drop when full — usually the oldest low-priority data, never alarms.
• Write in batches. Flash memory wears out with every erase cycle. Frequent small writes kill cheap flash fast. Use wear-levelling file systems and batch writes.
• Survive power loss mid-write. Use journaling or append-only logs so a brown-out doesn't corrupt the queue.

3. Trustworthy time

Offline devices lose network time. Timestamps become garbage, and garbage timestamps break sync and analytics.

• Use a real-time clock with a backup supply where timestamps matter.
• Keep a monotonic counter alongside wall-clock time, so ordering survives clock jumps.
• Correct drift when the network returns, and log the correction.

4. Sync that can't double-count

When a device reconnects, it may resend data the server already received. Make every message idempotent: give each event a unique ID so the server can safely ignore duplicates.

For configuration that can change on both sides, decide the conflict rule upfront. Usually the latest timestamp wins for settings, and safety-critical limits always come from a single authority.

5. Updates that can't brick the fleet

Over-the-air updates on flaky networks are where offline devices die.

• A/B partitions: download the new firmware into an inactive slot, verify it, then switch.
• Automatic rollback: if the new firmware doesn't confirm it booted healthily, the bootloader reverts.
• Resumable downloads: an interrupted update continues instead of restarting.
• Signed images: devices accept only firmware signed with your key.

6. Local interface

If users need to interact with the device during an outage, give them a local path — buttons, a display, a local web page or BLE connection to a phone. Offline doesn't mean unreachable.

7. A watchdog and honest status

A hardware watchdog restarts frozen firmware. A clear status indicator tells users whether the device is online, offline-but-working, or actually faulty. "Offline" and "broken" must never look the same.

How Draper handles it

Draper, our digital signage platform, stores its playlist and media locally and plays on schedule regardless of connectivity. When the network returns, it pulls new content and reports what actually played. Displays in retail and public spaces sit on the worst networks in a building. Designing for that reality is the product, not an edge case.

How to test offline behaviour

You don't know a device works offline until you've broken its network on purpose.

Run these in EVT, not after launch.

The trade-offs

Offline-first costs more firmware work upfront, more on-device storage, and more careful protocol design. In return, you get fewer support tickets, longer device life, lower cloud costs — less constant chatter — and a product that keeps working when a cloud provider changes its terms or prices. For most connected hardware, that trade is easy.

Questions founders ask

Keep reading