Progressive web app development

What WavX builds

WavX builds progressive web apps (PWAs) as custom web applications: a React or Next.js front end, a Node.js or Python back end, and PostgreSQL or MongoDB for the data. The PWA part is a defined set of additions on top of that application:

• a web app manifest, so that a browser can install the app under your name and icon
• a service worker with a caching plan written screen by screen, not one rule for the whole site
• an offline state for every screen that needs the network, so that the user sees a clear message instead of a browser error page
• an install flow for each platform, including written instructions for iPhone, where the browser shows no prompt
• push notifications where the platform supports them
• an update path, so that a new release reaches installed copies without anyone reinstalling

The result is one codebase, served from one URL, for phones, tablets and desktops. The PWA guide explains the idea for a non-technical reader.

What works on which device

Browser support decides what a PWA can promise, so this is where a project should start. The table shows the position as of October 2026, taken from the browser makers' own documentation. The sources are listed at the foot of this page.

Three points follow from the table.

Most Indian users get the fuller column. StatCounter puts Android at 93.89% of mobile operating system share in India for September 2026, and iOS at 6.05%.

The iPhone column still needs a decision. Without Background Sync, an order or a form saved offline on an iPhone cannot be sent while the app is closed. It has to go when the user next opens the app with a connection, and that path is built and tested separately. The detail is in what works in a PWA on iOS.

Not every browser installs. MDN records that Firefox on desktop does not install PWAs from a manifest, and that on Android only Chrome (on devices with Google Mobile Services) and Samsung Internet (on Samsung devices) install a WebAPK; other browsers add a home-screen shortcut that opens the site in the browser. web.dev notes that many in-app browsers, such as those inside Instagram, Facebook and Gmail, cannot install a PWA at all. A link shared on social media therefore needs an "open in your browser" hint.

What is in a build

The caching plan is where most of the judgement goes. A PWA that caches too much shows yesterday's prices; one that caches too little is a website with an icon. The patterns are set out in service workers and caching strategies.

How the work runs

1. Fit check. Before quoting, WavX lists the features you need against the table above and marks which ones a PWA cannot deliver on iPhone or in the browsers your users have. If the list fails, the recommendation is an app, not a PWA.
2. Offline map. Screen by screen: what must load with no connection, what may be a little stale, and what must never be stale.
3. Build. The web application first, then the manifest, the service worker and the install flow. A PWA must be served over HTTPS, so hosting and the domain are settled early.
4. Device testing. Installation, offline behaviour and updates are checked in each browser's own developer tools. In Chrome, the Application panel shows the manifest, the registered service workers and the cache contents.
5. Launch. The app goes live on your domain, in your hosting account. You own the code.

Work is quoted after a free consultation, as fixed price, time and materials, or a hybrid.

Planning ranges

A PWA is a web application, so WavX prices it from the software figures in its cost model, the ones the software cost estimator uses. There is no separate PWA rate card.

Assumptions for every row: the custom web application base of ₹4,50,000, small scale (×1.0) unless stated, standard design (×1.0), and a range of the subtotal ×0.85 to ×1.25.

These are planning ranges, not quotes. To reproduce a row in the estimator, set design to Standard; the estimator opens on Custom UI/UX, which multiplies the subtotal by 1.25. The timeline column is the cost model's band for a subtotal of that size, and the estimator displays its own band for the same selection.

Two kinds of work have no line in the model and are quoted after scoping: converting an existing website, and offline data handling that goes beyond cached pages, such as queued orders with conflict rules.

For comparison, the app cost calculator gives ₹5,48,250 to ₹8,06,250 for a medium cross-platform app with accounts, payments, push and an admin panel, and ₹8,77,200 to ₹12,90,000 for the same app built as two native apps. On WavX's own figures, then, a PWA is not cheaper than a cross-platform app. It is cheaper than two native apps, and it is one build where the alternative is often a website plus an app. The PWA cost guide works through the comparison.

When a PWA is the wrong build

• The app store is your main channel. If customers find products like yours by searching the Play Store or the App Store, build for the stores. A PWA can be packaged for them, but that is a second route with conditions each store sets.
• The product depends on background work on iPhone. Sync while the app is closed, or notifications to users who have not installed the app, are not available there as of October 2026.
• A plain website would do. A brochure site or a blog that nobody opens daily gains little from installation or offline support. Build the website and spend the difference elsewhere.
• The tool depends on attached hardware. An internal tool on company-issued Android phones is a good PWA. The same tool tied to a barcode scanner or other attached hardware may not be. Check what the browser on that device supports before committing.

The full comparison is in PWA vs native app. It is the right post to read before choosing, and WavX will say at the fit check if the answer is not a PWA.

PWA development is one part of web application development at WavX.