Choose Web Or PWA
Web is the default when the product can live inside browser constraints. PWA is the next rung when installability, offline behavior, or device integration matters but full native is not justified.
Decision Table
| Need | Pick | Why |
|---|---|---|
| Docs, reports, generated snapshots | Static output | Build once, host cheaply, minimal ops |
| Content-heavy site with a few interactive islands | Astro | Static-first with focused hydration |
| Private lab preview | Caddy tailnet | Fast, private, no public exposure |
| Shareable protected static surface | Static hosting plus Access-like protection | Reachable without tailnet while preserving auth boundary |
| Installable/offline workflow | PWA | Manifest, service worker, cache/IndexedDB, offline fallback |
| Auth, sessions, actions, server-only data | SSR/API runtime | Runtime exists for concrete server features |
| Heavy local service | Local service behind protected route | Do not convert everything to serverless if the workload is local/heavy |
PWA Minimum
A credible PWA needs:
- HTTPS in production.
- Web app manifest.
- Service worker.
- Offline fallback.
- Cache/update strategy.
- Install testing on target browsers.
- Device/browser compatibility checks for required APIs.
Avoid PWA When
- The killer feature depends on restricted mobile permissions.
- The app needs reliable background execution beyond web support.
- Store-native trust is a requirement.
- Browser differences create the core support burden.
Gotcha: A PWA is not a way to skip product testing. You still need Android Chrome, iOS Safari, install, offline, cache invalidation, and update-path checks.