A progressive web app (PWA) is a web application built with specific technologies—primarily service workers and a web app manifest—that allow it to behave more like an installed piece of software. A traditional web application runs in the browser and relies on a live server connection for each interaction, without those additional capabilities.
The practical distinction matters because it changes what the system can do when the network drops, how users find and return to it, and what the development team needs to build and maintain. For business systems such as CRMs, portals and internal tools, the choice between the two is not about trend-following. It is about whether those extra capabilities solve a real operational problem.
Compare the options before committing
| Comparison point | What to examine |
|---|---|
| What a PWA adds on top of a traditional web app | A service worker is a script that runs separately from the web page itself. |
| What stays the same | Both PWAs and traditional web applications run on the same underlying web technologies: HTML, CSS and JavaScript delivered through a browser engine. |
| When a PWA is worth the additional complexity | Field-service and logistics scenarios are the clearest fit. |
| When a traditional web application is the better choice | Most back-office systems—CRMs, admin panels, document management workflows, reporting dashboards—run on desktop machines or laptops with stable connections. |
| Development and maintenance implications | Building a PWA requires the development team to design an offline strategy from the outset. |
What a PWA adds on top of a traditional web app
A service worker is a script that runs separately from the web page itself. It sits between the application and the network, intercepting requests and deciding whether to serve data from the network or from a local cache. This is what makes offline or flaky-connection behaviour possible. Without a service worker, a traditional web application simply shows an error page when the network is unavailable.
The web app manifest is a JSON file that tells the browser how the application should appear when installed on a device: its name, icon, orientation and whether it should open in a standalone window rather than a standard browser tab. This is what allows a PWA to appear on a home screen or taskbar alongside native applications.
Web push is commonly implemented as part of a PWA-style capability set, using a service worker together with the Push and Notifications APIs. A browser-based application can support push where the target browser and operating system provide the required APIs, but installation, permission and background behaviour vary by platform. On current iOS and iPadOS, web push is available to Home Screen web apps rather than every ordinary browser tab.
What stays the same
Both PWAs and traditional web applications run on the same underlying web technologies: HTML, CSS and JavaScript delivered through a browser engine. Both can use the same backend services, databases and APIs. Both can implement the same business logic, user roles, permissions and workflows. A PWA is not a different category of software architecture; it is a traditional web application with additional browser-level capabilities layered on top.
This means the decision about PWA versus traditional web app is narrower than it first appears. You are not choosing between two fundamentally different systems. You are choosing whether to invest in the extra development work that service workers, manifests and offline strategies require, in return for specific behavioural improvements.
When a PWA is worth the additional complexity
Field-service and logistics scenarios are the clearest fit. If your staff use a web-based system on mobile devices while moving between locations with poor connectivity, the ability to cache forms, queue submissions and sync when the connection returns has direct operational value. The same applies to warehouse or manufacturing environments where Wi-Fi coverage is patchy.
Customer-facing portals where repeat engagement matters can also benefit. If users log in frequently to check order status, submit timesheets or approve documents, the ability to install the portal as an app and receive push notifications reduces friction compared to bookmarking a URL and remembering to check it.
Internal tools used on company-owned or BYOD mobile devices may justify PWA treatment if those devices leave reliable network environments. If the tool is only used at a desk on a wired or stable office connection, the PWA layer adds cost without solving a problem.
When a traditional web application is the better choice
Most back-office systems—CRMs, admin panels, document management workflows, reporting dashboards—run on desktop machines or laptops with stable connections. For these, offline capability provides little value. The data is typically too interconnected and too frequently updated to cache meaningfully. Attempting to make a complex CRM work offline introduces difficult questions about conflict resolution: what happens when two users edit the same customer record while offline and then sync?
Systems that rely heavily on real-time data—live dashboards, collaborative editing, stock-level displays—are also poor candidates for PWA offline features. The moment the data must be current, the cache becomes a liability rather than an asset.
If your primary audience uses older browsers or restricted corporate environments where service workers are blocked by policy, building PWA features means paying for capabilities your users cannot access.
Development and maintenance implications
Building a PWA requires the development team to design an offline strategy from the outset. This means deciding which data to cache, how to handle stale data, what happens when a queued action fails on sync, and how to communicate connection status to the user. These are not trivial design decisions and they add to both the initial build and ongoing maintenance burden.
Testing becomes more involved. A traditional web application can be tested against a known server state. A PWA must be tested across multiple network conditions—online, offline, slow connections, intermittent dropouts—and across different browser implementations of service worker behaviour, which still varies.
Updates to cached assets require careful versioning. If the service worker caches an old version of the application shell and the user does not close and reopen the application, they may run outdated code. The development team needs a strategy for cache invalidation and user notification that does not exist in a traditional web app, where a simple page refresh always fetches the latest version.
Risks and checks before choosing
Assuming offline means full functionality
The most common misconception is that a PWA works identically with or without a network connection. In practice, most business PWAs offer a degraded offline experience: users can view previously loaded data and queue simple form submissions, but they cannot run complex queries, generate reports or access records they have not recently viewed. If your supplier implies that the entire system will work seamlessly offline, ask specifically which features will be available, what data will be cached and how conflicts will be resolved.
Confusing PWAs with native mobile applications
Browser-delivered applications do not have uniform access to every device or operating-system capability. Bluetooth, NFC, advanced camera controls and background processing vary by API, browser and platform, and some scenarios remain more dependable in an installed native or cross-platform application. If the workflow depends on specialised hardware, verify the exact browser support on the devices in scope. For many CRMs, portals and document workflows, however, these limitations may not affect the core use case.
Overlooking browser and platform differences
Service worker behaviour, push notification support and installability differ between Chrome, Safari, Firefox and Edge, and between desktop and mobile versions of the same browser. A PWA that installs cleanly on Android Chrome may not offer install prompts on iOS Safari, or may handle background sync differently. Ask your development team for a compatibility matrix showing which PWA features work on each browser and platform your users actually rely on.
Adding PWA features as an afterthought
Retrofitting service workers and offline caching onto an application that was not designed for it is significantly harder than building those capabilities in from the start. The application architecture needs to separate the data layer from the presentation layer cleanly, use consistent API patterns and handle errors gracefully at every point. If you are considering a PWA, decide before the specification is finalised, not after the first build is delivered.
Key questions to put to a supplier
- Which specific PWA capabilities are you proposing, and which are you omitting?
- What is the offline strategy: full offline, partial offline with queued actions, or read-only cache?
- How will data conflicts be handled when two users modify the same record offline?
- Which browsers and devices have you tested, and where do PWA features degrade?
- What is the cache invalidation strategy, and how will users know they are running an outdated version?
- How much additional development and testing time do the PWA features add to the estimate?
- Will the application function correctly and securely if service workers are disabled or blocked?
When to decide
Current platform references
- MDN: Push API
- MDN: Service Worker API
- Apple Developer: web push notifications in web apps and browsers
The PWA decision should be made during discovery, not during development. It affects the architecture, the data-sync strategy, the testing plan and the estimate. If you are commissioning a business system and the supplier has not asked about connectivity conditions, device usage patterns and offline requirements early in the process, raise the question yourself before the specification is signed off.