What a PWA is, minus the jargon
A Progressive Web App is a website with app superpowers: installable to the home screen, able to work offline (or on bad networks), able to send push notifications where supported. Under the hood: a service worker (a background script that caches and intercepts requests), a manifest (name, icon, display mode), and HTTPS. No app store, no double the codebase, one URL. The question is never "can we make it a PWA", almost any site can, it is "would the superpowers get used?"
When PWA earns its build
- Repeat-use tools: dashboards, internal tools, field-service apps, anything users open daily, where install-and-home-screen removes friction and offline caching removes the "no signal" excuse. The internal tools page covers the service side.
- Connectivity-hostile workplaces: warehouses, sites, basements, flights, offline-first is a genuine feature there, and PWA delivers it without app-store distribution.
- Push-notification relevance: re-engagement (order updates, booking reminders) where the audience opted in, supported on Android and desktop; iOS push for PWAs arrived with recent Safari versions but with constraints worth checking per feature.
- Avoiding app-store gravity: no 30% cut, no review queue, instant updates. For many tools, that is the whole decision.
When it is fashion, not fit
Brochure sites, first-touch marketing pages, anything a visitor uses once, an installable icon on their phone is clutter, and the offline feature caches pages nobody returns to. Native apps still win where deep hardware access (Bluetooth, background sensors), app-store discovery, or platform-specific UX is the product. And the honest iOS note: PWAs on iOS have historically been second-class (storage limits, notification constraints), Apple has improved it, but check the current support matrix per feature before promising parity. The web application page covers the service framing for the app-shaped builds.
The build, scoped honestly
A PWA upgrade on an existing site is scoped work: service worker strategy (what caches, what falls back offline), manifest and icons, install prompts that do not nag, and the testing reality that offline behavior is state management, real engineering, not a plugin toggle. Bands ride the published context; the brief with your users' usage pattern starts the fit assessment, the honest first answer there is often "you do not need this yet," and that answer is free.