Why we built Nautilus offline-firstWhywebuiltNautilusoffline-first

Warehouses are hard on wireless. Metal racking, concrete, cold rooms that behave like Faraday cages, forklifts throwing electrical noise. WiFi works most of the time — but "most of the time" is not a foundation for a system operators rely on every few seconds. So we made a decision early: every action in Nautilus has to work without a network.

What offline-first means here

When an operator scans, counts, adjusts, or speaks a command, the app confirms it immediately on the device — it doesn't wait for a server to answer. The action is recorded locally and synced up when the network is available. To the operator it always feels instant, whether the signal is strong, weak, or gone.

The expensive, invisible engineering of an inventory app isn't the scanning or the AI. It's this sync layer underneath, and specifically what happens when several people change overlapping things while disconnected.

The problem with naïve queueing

The obvious approach — queue each operator's actions on the device and replay them when the network returns — works fine for one person and breaks the moment two people touch the same stock. Picture two pickers, both offline, both pulling from the same bin. Each sees the same starting count and each picks one. If their queues simply replay later, the counts and what each device believes can disagree, and the next sync looks like a glitch.

It gets harder when the conflicting actions are different kinds: one person adjusts a count while another relocates the item and a third is mid-audit assuming a fixed quantity. Replaying a queue in arrival order produces inconsistent state and confused, annoyed operators.

Resolving conflicts sensibly

So conflicts get resolved by rules that mirror what would have happened in the physical world. Two picks from the same bin don't really conflict — both are valid decrements, so they accumulate and the count lands correctly; we can optionally tell each operator a colleague also picked there. A relocation that conflicts with a pick yields to the pick, because in the real world the picker already grabbed the item. An adjustment beats almost anything, because it represents a human standing at the bin telling us what's actually there, and we trust that over the system's assumption.

A couple of hard-won principles

Treat the device as untrusted and tough. Warehouse devices get dropped, knocked off shelves, and run out of battery in bad moments. Hard crashes are routine, not exceptional, so anything that can't survive a device misbehaving doesn't belong on the device.

And optimize for perceived speed, not just real speed. An operator who scans and sees a confirmation instantly will call the app fast, even if the server finishes its bookkeeping a moment later. The local, optimistic confirmation is the thing they feel. Offline-first work is unglamorous and mostly invisible when it's done right — which is exactly the point.