"We need an app" usually means one of three things: a native app in the App Store and Google Play, a web application that runs in a browser, or a website that does more than a brochure does. These are different products with different costs, and the choice is worth making on purpose rather than by default.
Here is the set of questions we walk through with clients before anyone estimates anything.
Who is using it, and where are they?
Start with the person on the other end.
Office staff at desks, managers reviewing reports, and customers placing an order once a month are well served by a web application. They already have a browser open, and nobody has to install anything.
Field crews, drivers, people on a warehouse floor, and customers who use the product daily on their phones lean toward mobile. If someone pulls it out of their pocket ten times a shift, the app icon on their home screen earns its place.
Many businesses have both groups. That is common, and it does not automatically mean building two separate products.
What does it need from the device?
Some features need a native app or work much better in one:
- Reliable push notifications, especially on iPhone.
- Background location, such as tracking a route while the screen is off.
- Bluetooth, NFC, or other hardware access.
- Working offline for long stretches and syncing later.
- Heavy graphics or animation where every frame counts.
If your list includes these, mobile moves up. If your list is forms, lists, dashboards, scheduling, messaging, and payments, a web application can do all of it, and browsers handle more of the device features each year.
How will people find it?
A web application has a link. You can send it in a text, put it in an email signature, and let people use it without creating an account first. Search engines can index the public parts.
A native app has a store listing. That brings credibility and a home-screen presence, but it also adds a step: someone has to decide to install it. For products that people use occasionally, that step loses a lot of them.
What will it cost to keep running?
Native apps carry ongoing work that web applications mostly do not. Apple and Google release new OS versions every year and periodically change their requirements. Every update goes through store review. Users stay on old versions, so your server has to support several at once.
A web application updates for everyone the moment you deploy. For an internal tool or an early product that will change weekly, that difference matters more than it looks on paper.
There is a middle path
You do not always have to choose. A common approach is to build the product once as a web application and wrap it for the app stores, keeping the logic in one place and adding native pieces only where they are needed.
That is how we built Hookah Royale, a real-time multiplayer card game that runs on web, iOS, and Android from one codebase. A turn-based game did not need the performance of a fully native build, and keeping the rules in one place mattered more than squeezing out frames nobody would notice.
The middle path has limits. Products that need intense graphics, deep hardware access, or a very polished platform-specific feel are better built natively. But for most business software, it is a strong default.
A quick way to decide
- Mostly desk users, changes often, internal or B2B: start with a web application.
- Mostly phone users, daily use, needs notifications or location: mobile, or a wrapped web build.
- Both audiences: a web application for staff and admins, with a mobile experience for the people in the field. Often one codebase serves both.
- Unsure: build the web version first. It is faster to change, and real usage will tell you whether a native app is worth it.
The mistake we see most often is committing to three platforms on day one for a product whose core workflow has not been tested yet. Every platform you add before the idea is proven multiplies the cost of every change you will inevitably make.
If you are weighing this for your own project, tell us who is using it and how, and we will tell you what we would build first.