Offline-first

Offline-first is a design approach where an app treats the network as an optional extra rather than a requirement. The interface renders from locally stored data first and synchronises when a connection exists, so losing signal degrades one feature at a time instead of blanking the whole app.

Render first, fetch second

The defining habit of an offline-first app is that nothing waits for the network to paint. Layout, navigation and any static content appear immediately, and live data fills in afterwards. An app that waits for a database response before drawing anything shows a blank screen offline no matter how good its caching is.

The pieces that make it work:

  1. A service worker that serves the app shell, styling and previously seen images from cache.
  2. Local storage of the data itself — localStorage for small amounts, IndexedDB for anything structured or large.
  3. An explicit connection state in the interface. navigator.onLine plus the online and offline events is enough for an honest banner. Users accept "showing your last saved view" far better than a spinner that never finishes.
  4. Failure per feature, not per app. One failed call should disable one panel.

Writes are the hard part

Reading offline is a caching problem and mostly solved. Writing offline is a distributed systems problem and is not. Once you let users create records without a connection, you need a queue that survives a reload, retries that do not duplicate records if the first attempt actually succeeded, and a rule for what happens when the same record was changed on another device meanwhile.

That is why so many "offline" apps are read-only offline, and why it is an honest thing to ship.

The misconception

Caching pages is often mistaken for being offline-capable. They are different: a cached shell means the app opens, not that it works. Anything genuinely live still fails.

NorthernGo published apps (subdomain or custom domain) queue save() and delete() in the SDK when there is no network, and get() returns the last successful list plus any pending records (marked _pending: true). Login, payments, e-mail and AI still need a connection. The offline guide covers the two-state UI.

Frequently asked questions

Can users create data while offline and have it save later?

Only if the app implements it. Nothing in the browser queues failed writes automatically. The app has to store the pending record locally, detect when the connection returns, resend it, and handle the case where the record was already saved or changed elsewhere in the meantime.

Build it yourself

NorthernGo turns a plain-text description into a working web app with a database, login and a live URL. Local AI generation runs on your own GPU, is unlimited, and is free on every plan.

Start building free