Designing apps that assume the network is not there

Most apps treat offline as an error state. You get a gray screen, a retry button, and a spinner that means nothing. That's a defensible choice for a chat app. It's an indefensible one for a national park with no bars, a warehouse with a metal roof, or a plane. Offline-first flips the default: the network is a bonus, and the app is complete without it.

Decide what has to be fetched, and fetch nothing else

Start by listing the data your app needs and asking, honestly, which of it changes. Live scores change. A list of the 63 US National Parks does not.

Stampr ships that whole park dataset bundled in the app. It doesn't download a catalog on first launch, so there's no cold-start network request, no empty state while you wait, and no failure mode where the app is useless in exactly the place you'd want it: standing at a park entrance in a dead zone. The stamps themselves are rendered procedurally on the device, so the artwork isn't a download either.

That's the first design principle. If the data is small, slow-changing, or essential, put it in the binary.

Sync as little as possible, ideally nothing

The hardest part of offline-first isn't storage. It's reconciliation — two devices, two edits, one truth. Most of the complexity, most of the bugs, and most of the privacy exposure in a "works offline" app come from the sync layer, not the offline layer.

So the cheapest way to get sync right is to not have sync. DockLedger stores a whole depot's truck log, unload memos and discrepancy register on the device with no account and no internet. Tableside keeps game history on the phone with no sign-in, no sync, and no third-party SDKs. Both are single-device tools by design, and both are dramatically simpler and safer for it.

Every sync engine you don't build is a class of bug, an outage, a privacy policy, and a login screen that your users never have to meet.

Not every product can make that trade. But far more can than currently do, and the ones that can should stop apologizing for it.

What vanishes from the interface

Design offline-first and whole categories of UI stop existing. No sign-in wall before the first useful screen. No loading skeletons on your own data. No pull-to-refresh on things that can't have changed. No "syncing…" banner, no conflict resolution dialog, no offline mode toggle buried in settings.

What replaces them is directness. Tap, save, done, because the write went to local storage and there was nothing to wait for. That responsiveness reads as polish, but it's really just an absence — the absence of a round trip.

There's an honest cost, and it's worth naming. Your data lives on one device, so backup and device migration become real design problems rather than free side effects of a server. Features that genuinely need shared state, like live scores, still need a network, and pretending otherwise makes for a worse product.

The judgment call is per feature, not per app: what must be current, and what can simply be present. Get that split right and most of what people call reliability comes for free. That's the standard across our apps — private by default, and useful with the radio off.