PWA vs Mobile App: Why I Told a Client They Didn't Need an App

A client came to me with the budget approved and the decision already made. They wanted an app. iPhone and Android, in the store, icon on the home screen, the whole thing.

I told them not to build it.

Not because apps are bad. Because when we went through what they actually needed their customers to do, none of it required an app. Everything on the list — book, pay, check status, get a reminder — a website can do. And a website they could ship in a fraction of the time, update the same afternoon, and never submit to Apple for approval.

We built a responsive web app with PWA features instead. Their customers still get an icon on their home screen. There's just no app store standing between the business and its customers.

Here's the reasoning, in the same plain English I used in that meeting.

"We need an app" almost never means "we need an app"

When someone says they need an app, they're usually describing an outcome, not a technology. Push it one level and you get the real list:

• "I want to be on my customers' phones."
• "I want to send them notifications."
• "I want it to feel fast and modern, not like a clunky website."
• "I want to look like a real company."

Every one of those is achievable on the web today. None of them requires the App Store. They used to — around 2015, the gap between a native app and a website was enormous. That gap closed while everyone was still repeating the 2015 advice.

The question worth asking isn't "app or website?" It's "what does the app store actually buy me that I can't get otherwise?" For a lot of businesses, the honest answer is: a $99/year bill, a review queue, and a slower release cycle.

What is a PWA?

A PWA (Progressive Web App) is a website built so it can be installed on a phone and behave like an app. Same site, same URL — but the user can add it to their home screen, launch it full-screen without the browser address bar, use parts of it offline, and receive push notifications.

There is no download from an app store. There's no separate version to build. It's your website, with a few extra capabilities switched on.

The three pieces that make it work, without the jargon:

• A manifest — a small file that tells the phone your app's name, icon, and colors, so it installs cleanly to the home screen.
• A service worker — a bit of code that caches your app so it loads instantly and keeps working on a bad connection.
• HTTPS — a secure connection, which you should have anyway.

That's it. It's not a different kind of software. It's a well-built website that knows it might live on a phone.

Why a PWA is a real alternative to an app

Here's what my client got, next to what they thought they had to buy:

The row that decides most projects isn't a feature. It's "pushing a fix."

With a web app, you find a bug at 2pm and it's fixed for every customer by 2:30. With native apps, you fix it, submit it, wait for review, and then wait again for people to actually update — and a meaningful chunk of your users never will. You end up supporting three versions of your own product at once. That's not a technical inconvenience; it's an ongoing tax on a small team.

What you actually give up

I'd be selling you something if I said a PWA does everything. It doesn't. Here's the honest list of what you lose:

• Deep hardware access. Bluetooth accessories, background location tracking, advanced camera control, health data. If your product depends on these, you need a native app. Not "should consider" — need.
• App store presence. Some customers genuinely go to the App Store to look for a business. Whether that describes your customers is a real question, not a rhetorical one.
• The heaviest performance ceiling. Games, video editing, real-time 3D. If you're building that, you know it already.
• Some iPhone friction. On iOS, push notifications only work after the user adds your site to their home screen. That's an extra step you have to actively ask for.

Notice what's not on that list: booking, payments, accounts, dashboards, messaging, photo upload, forms, scheduling, reminders. That's the majority of business software, and it's all comfortably inside what the web does well.

The costs nobody puts in the pitch

Whoever quotes you an app quotes the build. The build is the cheap part. What actually shows up over the following year:

1. Two of everything. Two platforms means two builds, two test cycles, two sets of bugs, two release processes. Even with a cross-platform framework, you're testing on both and fixing platform-specific weirdness on both.
2. The review queue. Apple and Google decide when your fix ships. Usually it's quick. On the day you have an urgent problem, "usually" is not a plan.
3. Store fees and commission. $99/year to Apple, $25 once to Google, and if you sell digital goods in the app, a 15–30% cut of that revenue.
4. Install friction. A website is one tap from a link, a QR code, a Google result, or an email. An app is: go to the store, search, find the right one, download, wait, open, create an account. Every step loses people. You paid for the app; now you pay again to get people to install it.
5. Invisibility to Google. App content doesn't show up in search the way web pages do. If you want to be found by someone with a problem you solve, you want pages, not a binary.
6. The ongoing keep-alive. OS updates, SDK deprecations, and store policy changes force work on you whether or not you touched the product. An app you "finished" two years ago is not a finished app.

This is the same trap I wrote about in Why Your AI Project Is Stuck at 80% — the demo is fast and the last stretch is where the real cost lives. Native apps have a very long last stretch.

When a native app IS the right answer

I want to be clear that this isn't an anti-app argument. I'd tell you to build a native app without hesitating if any of these are true:

• You need hardware the web can't reach. Bluetooth devices, background GPS, health sensors, offline-first field work in dead zones.
• The app IS the product. If people will search the App Store for you specifically, and store presence is your distribution channel, that's a real business reason.
• You're selling to consumers who live in apps. Certain audiences and categories genuinely expect a store listing, and their absence from it reads as a red flag.
• Performance is the whole point. Games, media production, anything that needs to push the device hard.
• You have the team to sustain it. Two platforms, indefinitely, on top of the web presence you'll still need.

If none of those apply, an app is a preference, not a requirement. Preferences are allowed — they're just supposed to be priced honestly.

The four questions I'd ask before spending a dollar

This is the whole decision, compressed:

1. What do your customers need to do? Write the verbs down. If it's book, pay, view, submit, message, or track — the web does all of that.
2. Does any of it need hardware a browser can't reach? If yes, build native. If no, keep going.
3. How will people find you? If the answer is Google, a link, a QR code, or an email — those all lead to a website. Only the App Store leads to an app.
4. How fast do you need to fix things? If the answer is "same day," the app store isn't in a position to promise you that.

My client's answers were: book and pay; no; Google and email; same day. That's four for four pointing at the web. The decision made itself once the questions were on the table — which is generally how these go. The hard part is asking them before the budget is committed, not after.

It's the same shape of question as Do You Really Need a CMS? — the default answer everyone repeats is often the expensive one, and nobody checks whether it still applies.

What we built instead

One responsive web app. It works on a phone, a tablet, and a desktop because it was designed to, not because we built three of them. It's installable — customers who want the icon get the icon. It caches enough to survive a bad signal in a parking lot. It sends notifications.

And when something needed fixing, it was fixed and live the same day.

They didn't get an app. They got the outcomes they wanted an app for, sooner and cheaper, on infrastructure they can actually keep up with. If a native app ever becomes genuinely necessary, the web app doesn't get thrown away — it's the backend and the proof that the product works.

That's usually the right order anyway: earn the app, don't assume it.

FAQ

Q: What is a PWA in simple terms?
A: A PWA (Progressive Web App) is a website built so it can be installed on a phone and behave like an app. The user adds it to their home screen and gets an icon, a full-screen experience with no browser address bar, offline support, and push notifications — all without downloading anything from an app store.

Q: Is a PWA a good alternative to a native mobile app?
A: For most business software — booking, payments, accounts, dashboards, forms, messaging — yes. A PWA delivers the same customer-facing outcomes from one codebase, ships updates the same day, and stays findable in Google search. A native app is the better choice only when you need deep hardware access, maximum performance, or app store presence as a distribution channel.

Q: Can a PWA send push notifications on an iPhone?
A: Yes. Apple supports web push for PWAs, but only after the user adds your site to their home screen. That extra step means you need to actively prompt people to install it, unlike a native app where notification permission is part of setup.

Q: How much does a mobile app cost compared to a web app?
A: Beyond the build, a native app carries a $99/year Apple developer fee, a $25 one-time Google fee, a 15–30% commission on any digital goods sold in-app, two platforms to test and maintain, and ongoing work forced by OS and store policy changes. A web app has one codebase, no store fees, and no review queue.

Q: Do PWAs work offline?
A: Yes, for the parts you choose to cache. A service worker stores your app's files and key data on the device, so it loads instantly and keeps working through a dropped or weak connection. It is not unlimited offline access — you decide what stays available.

Q: Will I lose customers by not being in the App Store?
A: It depends entirely on how your customers find you. If they arrive through Google, a link, an email, or a QR code, a website removes friction rather than adding it. If they genuinely search the App Store for businesses like yours, that's a real reason to build native — but confirm it's true for your audience rather than assuming it.

Q: When should I actually build a native mobile app?
A: Build native when you need hardware a browser can't reach (Bluetooth accessories, background location, health sensors), when performance is the product (games, media production), when app store presence is your distribution channel, or when your audience expects a store listing. If none of those apply, an app is a preference rather than a requirement.

Related Reading

• Do You Really Need a CMS?: The same question, different technology — when the default choice everyone recommends is the expensive one.

• Outgrowing Excel: Why Web Apps Transform Business Operations: What a web app replaces, and the signs you've outgrown the spreadsheet.

• Don't Wait for the Fire to Buy Insurance: Why the web presence you build before you need it is the one that pays off.

• Why Your AI Project Is Stuck at 80%: The last stretch is where projects die. Native apps have a very long last stretch.

If you're sitting on an approved budget for an app and nobody has asked you these four questions yet, ask them now — before the money moves. Get in touch if you want a second opinion on the decision.