A website that can be installed on a phone, works without a signal, and sends notifications. No app store, no download, and some real limits worth knowing before you commit.
Underneath it's still your website. These are the capabilities that get layered on top of it.
Someone adds it to their home screen and it opens like an app, with your icon and no browser bar around it.
Why it mattersAn icon on a home screen gets opened. A bookmark doesn't.
Pages someone has already seen load instantly, and the app shows something useful instead of an error when the signal drops.
Why it mattersMatters most for people using it on the move or in buildings with poor coverage.
Messages that appear on the phone even when nobody has the site open, in the same way an app would.
Why it mattersThis is the capability people usually want an app for in the first place.
Worth being clear that a PWA is not a separate product. It's your existing website with these capabilities added, which is exactly why it costs a fraction of building an app and why it updates the moment you publish rather than waiting for an approval.
The honest comparison. A PWA sits in the middle, and where it falls short is specific rather than general.
What each one can do
The row that decides most projects is the last one. If a PWA covers what you need, you're adding capability to something you already have rather than starting a second product with its own budget, timeline, and maintenance.
This is where most PWA advice quietly stops being accurate. Support on iPhones is real and it isn't equal to Android.
The install prompt is the real problem. On Android, browsers offer to install your PWA and people accept. On iPhone, someone has to open a menu and choose "add to home screen", which almost nobody does unless told. If your audience is mostly on iPhones and installation matters to you, that's worth weighing seriously rather than discovering later.
A PWA is cheap relative to an app and it isn't free. Here's when the capability actually earns its cost.
Good reasons
People use it repeatedly
A booking system, a portal, an ordering tool. Anything someone opens weekly benefits from being one tap away.
Your users have bad connections
Field staff, warehouses, rural areas, or anyone using it while travelling. Offline capability is a genuine advantage here.
You want notifications without an app
Order updates, appointment reminders, alerts. The main capability people build an entire app for.
An app was quoted and it's too much
A PWA often delivers eighty percent of what was wanted for a small fraction of the cost, and it's worth checking before committing.
Not good reasons
A brochure site
Nobody installs a site they visit once to check your opening hours. The capability sits unused.
You want to be in the app stores
A PWA doesn't get you a store listing. If being findable in the App Store matters commercially, this isn't the route.
The site is already slow
A PWA layered on a slow site makes a slow app. Fix the underlying site first, and often that alone was the actual goal.
It sounds modern
If nobody can name the thing users will do with it, the honest answer is that you don't need one.
If you're weighing this against building a real app, the comparison is worth doing properly rather than on cost alone. The app side of that decision is covered under app development, and we'd give you the same honest answer from either page.
On top of your existing site where possible, rather than as a rebuild.
Which of the three capabilities you actually need. Building all three when you need one adds cost and complexity for nothing.
Speed and mobile experience come before anything else. A PWA amplifies whatever is already there, good or bad.
Installation, offline handling, and notifications if needed. Built to fail gracefully where a device doesn't support something.
iPhone and Android, installed and uninstalled, online and offline. This is where the differences between platforms actually show up.
Sometimes. If your app is essentially your website in a wrapper, which a lot of business apps are, then yes and you'd save the store fees and approval delays.
If it uses Bluetooth, runs in the background, or people find you by searching the App Store, then no. Those are the genuine dividing lines.
Considerably less, because you're extending something that already exists rather than building a second product with its own codebase and release process.
The ongoing difference is larger than the build difference. No store accounts, no submissions, no separate maintenance for two platforms.
Only if they have a reason to. Installation happens when someone already uses the thing regularly and wants it closer to hand.
What doesn't work is prompting a first-time visitor to install. It's the equivalent of asking someone to marry you on a first date, and it mostly annoys people.
Yes on WordPress, and it's straightforward. Shopify is more restricted because you don't control everything the platform loads.
On both, plugins exist that claim to make your site a PWA in one click. They technically do, and what they produce is usually installable and not much use.
Whatever we decide it should. Pages they've already visited load from the phone, and anything else shows a message that makes sense rather than a browser error.
Actions taken offline can be queued and sent when the connection returns, though this needs designing carefully so nobody thinks something saved when it didn't.
Being a PWA isn't itself a ranking factor. What helps is that the work involved usually makes a site considerably faster, and speed does matter.
The real advantage over an app is that a PWA is still a website, so it can be found in search. Apps can't. That's covered further under technical SEO.
Usually added to a site rather than built as a separate project. Pricing sits on the main web development page.
Related services
Thirty minutes on whether a PWA covers it, or whether you genuinely need an app.
Or email hello@culmen.digital