Open your phone and count the apps you haven't touched in a month. For most people, it's a surprising number. A parking app from a trip last year. A loyalty app from a café you visited twice. An app your bank asked you to install for one verification, and never again.
Every one of those apps was somebody's big decision. Someone in a meeting said "we need an app", a team spent months building it, and it ended up on a home screen, then in a folder, then deleted.
"We want an app" is often the first sentence in a new software project. It sounds like a decision, but usually it's a picture: an icon on a phone, a listing in the app store, something that feels like a real product. Sometimes that picture is right. Often it isn't, and the product pays for it with a bigger budget, more friction for users and an install that people only open once a month.
This article is a practical way to decide between a web app and a native app, especially for products businesses use.
App fatigue is real
In many countries, and Indonesia is a strong example, almost everything now asks for its own app. Groceries, taxes, motorbike installments, parking, the gym, the clinic and the school. Each one wants a download, an account, permissions and notifications.
People have adapted in a predictable way: they install less, delete more and quietly ignore most notifications. An app has to earn its place on someone's home screen by being used. If it isn't opened often, it becomes clutter.
The data from app analytics companies has told the same story for years. Localytics, which tracked usage across thousands of apps, repeatedly reported that roughly one in four users opens an app only once and never comes back. Getting installed is hard. Staying installed is harder.
That leads to the first rule.
Question one: how often will it be used?
A product that isn't used often shouldn't be an app.
If someone opens it once a month to check a balance, pay a bill or confirm a booking, a web page they can open from a link or a bookmark is less work for them than an app they have to find, update and sign into again.
For business products, this question usually has two answers, because there are usually two kinds of users. Take a membership business:
Staff and front desk use the system all day, every day, to check people in, take payments and see who needs attention.
Members use it rarely: to sign up, pay or check their status now and then.
For members, the rule clearly says no app. For staff, it says yes. That's where the second question matters.
Question two: where will it be used?
When people hear "app", they picture a phone. That's often the wrong picture.
Front desk staff use their system every day, but they use it at a counter, on a computer. If a system like that ever needed an app for staff, the sensible one would be a desktop app, not a phone app. A phone app for a job that happens at a desk is an expensive mistake.
Even a desktop app is often unnecessary. Think about the online tools many professionals use daily, like hosting dashboards, project boards and email. Many people open them in a browser tab from a bookmark rather than hunting through a start menu for an installed program. The browser is already open. The bookmark is already there.
So before you decide on an app, write down where the work actually happens: at a desk, at a counter, on the road or in a pocket. The right format usually follows.
Question three: who has to install it?
An install is a small ask, but it's still an ask. It matters most for users who didn't choose the product for its software.
Staff will install what their employer tells them to. Customers are different. A gym membership, a class pass or a coworking plan is something people join by choice, as part of a lifestyle. Putting "download our app first" at the door of that decision is the wrong kind of friction. Every extra step between interest and sign-up is a place where someone drops off.
There's also a practical reason. Not every customer has the latest phone, enough storage or the patience for another account. A link that opens in any browser works for all of them.
What you give up without an app
Mostly, push notifications. That's the honest trade-off. Without an app, you can't tap people on the shoulder through their phone's notification system.
For many businesses, it matters less than you'd expect, for two reasons.
The business already has a touchpoint. If customers physically come in, the business already has a way to reach them that no app can match. When a front desk sees a membership has seven days left, staff can simply mention it to the person standing in front of them.
People already live somewhere else. In Indonesia, that place is WhatsApp. A reminder there gets seen within minutes, while a push notification from a rarely opened app is easy to ignore. Your market might live in email, SMS or another chat app. Find where people already are before you build a new place for them to go.
If your business has neither, no physical touchpoint and no channel people reliably check, push notifications matter more, and that's a real argument for an app.
What you gain with the browser
The biggest gain shows up in a question every business customer eventually asks: "Can we open it on this?" The old computer at the front desk, the owner's laptop at home, a tablet, a cheap phone.
With a web app, the answer is always yes, as long as there's a browser. For a business buyer, that's a selling point, not a technical detail. It means no hardware requirements, no compatibility list and no waiting for IT.
Other gains come with it:
Updates reach everyone at once. A fix shipped today is live for every user the next time they load the page. Nobody has to update anything.
One product to build and maintain. No separate versions for iOS, Android and desktop, each with its own release cycle and review process.
No app store in the middle. No review delays, no store fees and no risk of a rejected update blocking an urgent fix.
Browsers can do more than people think. A web app can use a phone's camera to scan QR codes, work with physical scanners and connect to other hardware through the right integrations.
What other companies learned
Large companies have run this experiment in public, and the results are instructive.
Starbucks built a progressive web app for ordering in 2017, a web app that loads quickly, can be added to the home screen and keeps working on weak connections. In the case study Google later published, the web version was a tiny fraction of the size of the iOS app, and daily active users on the web roughly doubled after launch. Many of those new users were on desktop, a place the native app never reached.
Twitter launched Twitter Lite, also a progressive web app, the same year, aimed at people on slow networks and cheap phones. It was under one megabyte. Twitter reported people browsing more pages per session and sending more tweets than before.
In business software the pattern is even clearer. Figma launched in 2016 as a design tool that ran entirely in the browser, at a time when every serious design tool was installed software. Skeptics said professional design couldn't work in a browser. Being browser-first turned out to be its advantage: sharing a file was as easy as sharing a link, and a whole team could work in the same file at once. Adobe agreed to acquire it for about US$20 billion in 2022, a deal that was later called off. Google Docs, Canva and Notion made the same bet and won large audiences with it.
None of this means native apps are obsolete. It means that for many products, the browser is not the compromise option. It's often the one that reaches the most people with the least friction.
It still has to be built properly. A product that's reachable from any browser has to take security seriously at every layer. That's work you do once, and it protects every device.
When you really do need an app
None of this makes apps wrong. Some products need one, and for them it isn't a choice. It's what the product is.
These are usually products designed around the phone from the start, where the phone's hardware, its location or its constant presence in someone's pocket is the point. Take the phone away and there's no product left.
An app is also worth a closer look if:
Your users need to be reached instantly and have no other channel you can rely on.
The work happens away from a desk and away from a connection, so offline use really matters.
People will genuinely open it every day, on their phones.
Real examples make the line clearer. A ride-hailing driver needs the phone's location, background updates and instant alerts while driving, so an app is the product. A mobile banking app leans on the phone's security features, like biometric unlock and secure storage, so an app makes sense. A field sales team visiting shops in areas with poor signal needs something that works offline and syncs later. In each case, the reason is concrete and tied to the phone itself.
Compare that with a monthly invoice portal, a booking page or an owner's dashboard checked twice a week. Nothing about those depends on the phone. They depend on being easy to open.
If none of the app conditions describe your product, an app is probably something you'd be building for the picture, not the need.
The hidden costs of an app
It's also worth counting what an app costs beyond the first build, because those costs are easy to miss in a proposal:
Two platforms, or three. iOS and Android usually mean two codebases, or a cross-platform framework with its own quirks. Add a desktop app and it's three.
Store reviews. Every update goes through Apple's and Google's review processes. An urgent fix might wait a day or more.
Store fees. Digital purchases inside apps are often subject to the stores' commission, which has historically been up to 30 percent.
Old versions in the wild. Some users never update, so you support several versions of your product at once.
Operating system changes. Every year brings new rules around privacy, notifications and background activity that apps have to adapt to.
A web app has maintenance costs too, but it has one version, deployed once, for everyone.
A quick way to decide
Run through five questions. Each answer points one way or the other.
Question | Points toward a web app | Points toward an app |
|---|---|---|
How often is it used? | Weekly, monthly, occasionally | Several times a day |
Where is it used? | At a desk or a counter | On the move, from a pocket |
Who has to install it? | Customers who can walk away | Staff, or users who depend on it |
How do you reach users? | Face to face, WhatsApp, email | Only through the product itself |
Is the phone the product? | No | Yes |
If your answers land in both columns, that's normal. Business products often have one group of users on each side. Decide per group, not for the product as a whole.
An example
Memverr, the member management platform we built, went through exactly this decision. Its earliest concept was a native app that members would install. What shipped instead runs entirely in the browser. Members sign up and pay from any phone without installing anything, staff use it at the front desk and WhatsApp handles the reminders. Nobody has asked for a desktop app, so it hasn't been built.
Start from the need
When someone says "we want an app", the most useful response isn't yes or no. It's a question: what's the need, in practice, and why? Who uses it, how often, where, and what are they trying to get done?
Sometimes the answer really is an app. Often, once you look at how the work actually happens, it isn't. Start from the need, and the format follows.
Layerice is a software design and development studio for businesses. We build on the web or as apps, depending on what the product needs.