Web app vs mobile app: the decision before the build
A founder we worked with last year came to the kickoff certain about one thing: she needed an iOS app. Her product was a scheduling and billing tool for independent physiotherapists, the kind of work that happens at a desk between patients, on a laptop, with a second monitor showing the day’s calendar. She wanted it in the App Store anyway, because that was what a real product looked like to her. We built her a web app instead. Eighteen months later she has paying clinics in three states and has never once wished for the native app she asked for on day one.
That is the whole web app vs mobile app question in one story. A web app runs in a browser and works on any device that can open a URL. A mobile app is installed from an app store and runs natively on a phone. Choosing between them is not a choice about which technology is more modern. It is a question about where your customers actually do the job, and what that job needs from the device in their hand. Answer that honestly and the platform falls out of it.
Most early-stage founders get pushed the other way. App-store instinct says “serious companies have an app,” so they pay to build and maintain two platforms to reach customers who would have been just as well served by one good web app. This is a guide to making that call from the founder’s seat instead of the developer’s, with a framework you can run in an afternoon.
Three things founders keep conflating
Before the decision makes sense, three words have to come apart, because founders use them interchangeably and then buy the wrong thing.
A website is content you read. A marketing site, a blog, a landing page. Nobody logs in to do work.
A web app is software that runs in the browser and that people log in to use. Gmail is a web app. Figma is a web app. Your bank’s dashboard is a web app. It lives at a URL, updates the instant you ship, and works on a laptop, a tablet, and a phone browser without you building three versions. A progressive web app, or PWA, is a web app that can be saved to a phone’s home screen, work partly offline, and send push notifications. It looks and feels close to an installed app without going through a store.
A mobile app is the thing you download from the App Store or Google Play. It runs natively on the phone, can use the camera, GPS, Bluetooth, and the full notification system, and works offline by default. Building one usually means building it twice, once for iOS and once for Android, or using a cross-platform framework to share code. That second decision, native versus cross-platform, only matters once you have decided you need a mobile app at all.
Hold those three apart and most of the confusion in the “web app vs mobile app” debate disappears. A lot of founders think they need a mobile app when what they need is a web app that happens to work well on a phone.
The real question isn’t web vs mobile
Here is the move that saves founders the most money: stop comparing the platforms and start describing the job.
The platforms are just delivery mechanisms. What matters is the work your customer is doing when they reach for your product, and where they are when they do it. A field technician photographing a damaged meter on a rooftop with no signal is doing a different job than an operations manager reconciling invoices on a Tuesday afternoon. The first needs the camera, GPS, and offline storage, so it wants to be native. The second needs a real keyboard and a big screen, so it wants to be a web app. Neither founder should start from “iOS or browser.” They should start from the rooftop and the Tuesday afternoon.
This is why the SERP full of “20 pros and cons” lists is useless to you. Pros and cons in the abstract are noise. The same feature that is a pro for a consumer fitness app, push notifications nudging you to close your rings, is irrelevant for a B2B tool people open when an email tells them to. You do not need a feature matrix. You need to know your customer’s day.
The four questions that actually decide it
Run your product through these four. The answers point at web app, PWA, or native far more reliably than any generic comparison table.
1. Where does the job physically happen? At a desk, on a laptop, with other tabs open? That is web app territory, full stop. On the move, in the field, in a store aisle, in a car, away from a keyboard? That pulls toward mobile. Be honest about where the actual work occurs, not where you imagine users daydreaming about your brand.
2. What does the job need from the device? List the hardware and OS features the core task genuinely requires. Camera for document or barcode capture. GPS for location. Bluetooth for a device. Reliable offline use with no signal. Rich push notifications that have to land even when the app is closed. If your core job needs two or more of these deeply, a native app earns its cost. If it needs none of them, you are paying for a native app to deliver a web experience.
3. How often do customers come back, and through what door? A tool people use daily, that they want one tap away on the home screen, benefits from being installed. A tool people use weekly or monthly, that they reach by clicking a link in an email or a Slack message, is better as a web app. Discovery matters here. If your customers find you and return through email, search, and shared links, a URL is your front door. An app store listing is not.
4. What can you afford to build and maintain over 18 months, not just to launch? This is the question founders skip and regret. A native app is rarely one build. It is iOS plus Android, two app-store review processes, OS updates that break things twice a year, and a release cycle where fixing a bug means waiting on Apple’s reviewers instead of shipping in an hour. Building for two native platforms typically runs meaningfully more than a single web build, and the maintenance gap compounds every quarter after launch. If your runway is tight, every platform you add is a tax you pay forever.
If three of the four answers point at the browser, build the web app and stop talking yourself into more. If three point at the phone, the native cost is justified. When they split, the next two sections are for you.
When a web app or PWA is the right call
For most B2B products, internal tools, dashboards, marketplaces, and anything people use at a desk, a web app is not the compromise. It is the correct answer.
You ship the moment you deploy, with no store review sitting between you and your customers. One codebase serves laptop, tablet, and phone browser. Onboarding is a link, which is the lowest-friction distribution there is. And when a customer hits a bug on a Friday, you can fix it on Friday, not next Tuesday after a reviewer wakes up.
If your product wants a foot on the phone without the full native cost, a PWA is the underrated middle. Customers can add it to their home screen, it can work offline for cached data, and it can send push notifications on Android and, increasingly, on iOS. It will not match a native app for heavy graphics, deep hardware access, or the polish of platform-native gestures. For a large share of founder products, it does not need to. The honest tradeoff is that PWAs lose to native on raw capability and gain on cost and speed of iteration. For a tool people log into to get work done, that trade usually favors the web. Google’s own guidance on progressive web apps is a good primer on what they can and cannot do today.
When you actually need a native app
Sometimes the phone is not a nice-to-have. It is the product.
Build native when the core job lives on the phone and leans hard on the device: a navigation app, a camera-first product, a delivery or logistics tool used in the field, anything needing reliable offline operation, real-time location, Bluetooth hardware, or notification reliability you cannot compromise. Build native when daily, habitual use is the whole retention model and the home-screen icon is doing real work to bring people back. Build native when performance is the experience, where a half-second of jank reads as broken.
If that is you, the native cost is not waste. It is the price of the product working at all. The point of the framework is not to talk you out of native. It is to make sure you are paying for native because the job demands it, not because the App Store felt like a milestone.
“Which should you build first?”
This is the question half the SERP promises to answer and then dodges. Here is the honest version.
For most founders, build the web app first, even if you are confident a native app is in your future. The web app is cheaper, ships faster, runs on every device your earliest customers own, and teaches you what the product should be before you commit to the more expensive platform. You learn which features matter, which screens people live in, and which parts of your day-one plan were wrong. Then, if the four questions still point at native, you build it knowing exactly what to build, on top of a backend the web app already proved.
The exception is the small set of products where the phone is the entire experience from the first day, where a web app would not be a smaller version of the product but a different and worse one. A consumer app whose whole pitch is camera-plus-location has no useful web-first version. For everyone else, web first is not settling. It is sequencing, and it is the same discipline behind a real minimum viable product: build the smallest thing that does the job well, learn, then expand the surface deliberately. The web-app-vs-mobile-app decision is one instance of the broader build versus buy versus sequence judgment every founder makes a dozen times.
The app store is distribution, and distribution has a price
One more thing the “serious companies have an app” instinct misses. The App Store and Google Play are not just a place to put your app. They are a distribution channel, and channels charge rent.
That rent comes in three forms. There is the commission, historically 15 to 30 percent of anything you sell through the app, though Apple’s small-business program lowers it to 15 percent under a million dollars a year. There is review latency: every release, including the urgent fix, waits in a queue you do not control. And there is discovery, which founders most overestimate. Nobody is browsing the store and stumbling onto your B2B scheduling tool. You will market it through the same channels you would market a web app, then ask people to go install it, adding a step. The store is a toll booth you choose to drive through when the native experience is worth the toll. It is not free reach, and it is not a trophy.
None of this means avoid the App Store. It means count it as a cost, the way you count any other, instead of treating “we’re in the App Store” as a goal that pays for itself. It rarely does on its own.
The founder with the physiotherapy tool understood this once we laid it out. Her customers were at desks, the job needed a keyboard and a screen and nothing from the phone’s hardware, they came back through email reminders, and her runway could not carry two native builds. Every one of the four questions pointed the same way. The native app was never the product she needed. It was the picture in her head of what a product is supposed to be. The job, once she described it plainly, had already chosen the browser.
FAQ
Which is better, a mobile app or a website?
Neither is better in the abstract. A website is for content people read; a web app is software people log into; a mobile app is installed from a store and uses the phone’s hardware. The right one depends on where the job happens and what it needs from the device. For most desk-based and B2B products, a web app wins on cost, speed, and reach. For field, camera, or daily-habit products, native earns its keep.
Can a web app be a mobile app?
In effect, yes, and that is what a progressive web app is. A PWA runs in the browser but can be saved to the home screen, work offline for cached data, and send push notifications, so it behaves much like an installed app without going through an app store. It will not match a native app for heavy hardware use or graphics, but for many products it closes most of the gap at a fraction of the cost.
Why is PWA not popular?
PWAs are widely used, just quietly. Plenty of products you use are PWAs without announcing it. The perception that they are unpopular comes from two things: iOS supported them later and more partially than Android, and there is no store listing to make them visible, so adoption is invisible by design. For founders that invisibility is a feature, since distribution happens through your own links rather than a crowded store.
Is Facebook a web app or mobile app?
Both, and that is the point. Large companies run a web app and native iOS and Android apps in parallel because they have the budget and the user base to justify every platform. That is the wrong model to copy at the early stage. Big apps are everywhere because they can afford to be, not because every product needs to start that way. Pick the one platform your customers’ job actually requires, prove it, then add surfaces when the numbers, not the instinct, say so.