Max
Back to Blog

Built to Work Without Signal: Field Notes on Offline-First PWA Design

Taiwan Trail Stewardship is a platform where hikers report trail conditions. It has one very particular requirement: the primary usage scenario is in the mountains, where there is often no signal. If the site stops working offline, the product loses its purpose. So from day one the architecture was offline-first — treating offline as the norm, not the exception.

The Service Worker is the core

A PWA's offline capability comes from the Service Worker: a proxy layer between the page and the network. The app shell, styles, scripts, and base trail data are pre-cached while the user still has connectivity, so the site opens instantly with or without signal. Caching strategies are split by resource type — cache-first for static assets, stale-while-revalidate for changing data, and submitted reports go into a queue that flushes when the network returns.

The offline user experience

Being offline should not look like an error screen. A report filled out on the mountain is saved locally first, and the UI clearly says 'saved — will be submitted when back online'; once signal returns, background sync flushes the queue automatically. The design principle here is honesty — the user always knows where their data is and what state it is in. That is how trust is built.

Charts and the back office

Trail statistics are drawn with D3.js. The data is pre-aggregated into lean JSON on the server, so the frontend only renders — charts stay smooth even on low-end phones. The back office runs on Drupal 10: content moderation, tiered permissions, and editorial workflows are CMS strengths that need no reinventing, freeing engineering effort for the offline experience.

Takeaway

Offline-first is not just adding a cache. It touches every layer of the data flow: what to pre-cache, what to queue, how to resolve conflicts, how the UI tells the truth. But done right, the product reaches places ordinary websites cannot — literally.