The cheapest AI app to run is one where the user’s own machine does the work. Your server hands out files, the browser downloads a small model once, and every inference after that happens on the visitor’s GPU or CPU. You pay for static hosting. That’s it.

This used to be a demo trick. In 2026 it’s a reasonable way to ship a real tool. WebGPU now runs in Chrome, Edge, Safari 26 and up (iPhone and iPad included) and Firefox on Windows and Apple Silicon Macs. Transformers.js v4 runs vision, speech, embedding and classification models on WebGPU and falls back to WebAssembly when there’s no GPU path. The pieces are boring enough to build on.

Take a field technician who edits a work order on a tablet in a basement with no signal. Upstairs, the office edits the same order from a desk. Both hit save at 10:42 by their own clocks, and one of those clocks is ninety seconds off. When the tablet finds a signal, the sync layer has to produce one order that both people can live with. That decision is the product. Offline-first apps are harder than they look, and a large share of the difficulty sits in this one step.

The default architecture for most mobile applications treats network connectivity as a reliable precondition. API calls are made on demand. Failures produce error states. The user waits for responses. This architecture produces apps that work acceptably on fast, reliable connections and badly on slow, intermittent, or absent connections — which describes the conditions under which many mobile users actually use apps.

Offline-first architecture inverts this assumption. The app reads from and writes to local storage first. Network synchronization happens in the background, opportunistically, whenever connectivity permits. The user experience is fast and available regardless of network state. The complexity is in the synchronization layer, which most teams underestimate significantly before they build it.