The installable app that is still a website
A progressive web app is a website that can be installed to a device's home screen, work without a connection, and send notifications on supported platforms. It needs no store approval, updates the moment you deploy, and remains fully indexable by search engines.
For a large share of projects that arrive described as app requests, this is the honest answer. The business wants an icon on a phone and the ability to work in poor connectivity. Both are achievable without two native codebases, two store review processes, and the persistent problem of convincing anyone to install anything.
The costs of the app store route are paid continuously and rarely priced at the start. Every release waits for review. Every operating system update risks breaking something that worked. Two platforms mean roughly two maintenance commitments for one product. And the install barrier is real, a customer who would have followed a link will frequently not download an application to complete one task. Content inside a native app is also invisible to search engines, which quietly removes the channel that found those customers.
When this work makes sense
Questions worth asking any supplier
Which device capabilities do you genuinely need? Most business requirements are within reach of the web.
How important are push notifications on iOS? Support exists but is more constrained than on Android.
Does the content need to be indexable? A native app's content is invisible to search engines.
How often will you release? Store review adds delay to every update; a progressive web app ships immediately.
Is store presence itself a requirement, for procurement or credibility reasons? Sometimes it genuinely is.
Deliverables
An installable application meeting the criteria browsers require to offer installation
Service worker handling caching and offline behaviour for the cases you specify
Offline data strategy, including what happens to actions taken while disconnected
Push notifications where the target platforms support them
Responsive interface designed for touch rather than adapted to it
Search-indexable content, since the application is still a website
Install prompting at a sensible moment rather than on first page load
Built with
Process
Progressive web app work is scoped around a specific question early: exactly what must function without a connection. Offline is not a single feature but a spectrum, viewing cached content, queuing actions for later, or full bidirectional synchronisation with conflict resolution. Those are very different amounts of work, and projects that leave the question vague tend to discover the expensive end of it late.
The standard nine stages, discovery, strategy, UX/UI, development, content and SEO, testing, launch, measurement and continuous improvement, apply to every project. The paragraph above is what differs for this one.
What moves the number
Pricing depends on scope, functionality, integrations and content requirements. These are the factors that change it most:
Progressive web app, native app, or a responsive site
Responsive website
Fits: Content, commerce and most business use, nothing to install
Limits: No home-screen presence, no offline capability, no notifications
Progressive web app
Fits: Repeat-use tools and content where install and offline matter
Limits: Some device capabilities remain out of reach; no store listing
Native app
Fits: Deep hardware integration, background processing, or where store presence is required
Limits: Two codebases, store review on every release, and the install barrier
Case studies
No published progressive web app case study yet.
MBGDesk operates from 4 offices in India, United States, United Kingdom, United Arab Emirates. We hold no industry certifications and do not imply otherwise.
Frequently asked questions
Do progressive web apps work on iPhone?
Yes, they install to the home screen and run standalone. Support for some features, push notifications in particular, has historically lagged Android and carries more conditions. If notifications on iOS are central to the product, that needs checking against current support before committing.
Can we put it in the app stores?
There are wrapper approaches that place a progressive web app into store listings, and they work with caveats around review policies. If store presence is genuinely required rather than assumed, that is worth establishing before choosing the approach.
How much can work offline?
As much as you specify and pay for. Cached content offline is straightforward. Queuing actions for later is more work. Full two-way synchronisation with conflict resolution is a substantial engineering problem in its own right.
Will it still appear in Google?
Yes, and this is one of the strongest arguments for the approach. It remains a website, so its content is indexable. A native app's content is not, which means a business that moves content into an app loses the search channel entirely.
How do users know they can install it?
Browsers offer installation when the technical criteria are met, and you can prompt at a chosen moment. Prompting on first visit performs poorly; prompting after someone has used the thing twice performs considerably better.
Is this cheaper than a native app?
Usually and substantially, because there is one codebase rather than two, no store review cycle, and no separate release process. The saving continues after launch rather than being a one-off.
How do people get updates once they have installed it?
Automatically, but not always instantly, and this is the main operational gotcha. A service worker caches the application, so a returning user may load the cached version before the new one is fetched. That is a feature, it is what makes the thing work offline, and it needs a deliberate update strategy, usually notifying the user that a new version is ready rather than swapping it underneath them mid-session.
Services that connect to this
Talk to us about this
Tell us what you are trying to build and we will come back with scope, approach and an estimate.