"We need an app." It is one of the most common opening lines we hear, and one of the most expensive sentences to take literally. Launching on iOS, Android, and the web at the same time triples the surface area of a first release, and most products do not need it.
This guide helps you choose one place to start, based on your users, your features, and what you can maintain.
First, separate three things
People say "app" to mean several different products:
- A web application: runs in the browser, works on any device, no installation. Think dashboards, portals, booking systems, internal tools.
- A native mobile app: built for iOS or Android, installed from the store, with full access to the device—camera, GPS, notifications, offline storage.
- A cross-platform mobile app: one codebase producing iOS and Android apps, with most native capabilities and some trade-offs.
Each is a good answer to a different question.
Start with a web app when…
- Users are at a desk or switching between devices.
- The product is used occasionally rather than many times a day.
- You need to iterate fast: web releases ship instantly, with no store review.
- Search matters: web pages can be found; app screens cannot.
- The audience is broad and you cannot predict their devices.
Most business software, customer portals, and admin tools belong here. A well-built web app installs to the home screen and works offline for common tasks, which covers more "we need an app" cases than people expect.
Start with a mobile app when…
- Users are on the move and use the product many times a day.
- You need the camera, GPS, background location, push notifications, or reliable offline work.
- The experience depends on speed and touch—logging deliveries, scanning, field inspections, quick check-ins.
- Being on the home screen and in notifications is part of the value.
Field operations, delivery, attendance, and consumer products with daily habits usually belong here.
Native or cross-platform?
If you have decided on mobile, the next question is how to build it.
| Native (Swift / Kotlin) | Cross-platform (one codebase) | |
|---|---|---|
| Performance and device access | Best | Very good for most apps |
| Cost of two platforms | Two codebases | One codebase, shared logic |
| Platform look and feel | Exact | Close, with care |
| Best for | Demanding graphics, deep OS integration | Most business and consumer apps |
For most organizations, a cross-platform build is the right first release: one team, one codebase, both stores. Go native when the product's core depends on something only native does well.
A decision path
- Who uses it, where, how often? Desk and occasional → web. Mobile and daily → mobile.
- Which device features are essential? None → web. Camera, GPS, offline → mobile.
- Does discovery matter? Need to be found by search → web, at least for the public part.
- How fast must you iterate? Weekly changes → web first, mobile once the product settles.
- What can you maintain? Be honest. A web app is one deployment; two native apps are three.
Many products end up with a web application at the core—where the data, the admin, and the reporting live—and a focused mobile app for the people who need it in their pocket. That is not indecision; it is the shape of most successful systems.
What a focused first release looks like
Pick the three journeys that deliver the product's value. Build those properly, with real data, on one platform. Launch to a small group. Learn. Then extend. Every feature you leave out of the first release is a feature you can build knowing what users actually do.
Frequently asked questions
Can a web app send notifications and work offline? Yes, within limits. Modern web apps can be installed, store data offline, and send notifications on most platforms. For heavy offline use or background work, native apps are still more reliable.
Will we need to rebuild later if we start with web? Not usually. The backend—your data, logic, and APIs—serves both. A later mobile app connects to the same system.
How do we get into the app stores? Both stores review apps before publishing. Plan for listings, screenshots, privacy details, and review time in the launch schedule. We handle this as part of app development.
Not sure which side you are on? Describe the product and its users in a few lines and send it to us. We will tell you where we would start—and what we would leave out.