PRACTICAL GUIDE
Web app or mobile app: which should you build first?
Start with where your users are and what they need to finish. The first platform should make that task easy to try, while supporting the capabilities the product depends on.
1. Start with the situation, not the platform.
Where will someone be when they need your product? A customer opening a booking link, an analyst working with a large spreadsheet, and a technician recording work away from a reliable connection have different needs. Write down the device, setting, and task before choosing a platform.
A web app runs in a browser and can be designed for phones as well as computers. A mobile app usually means software installed on iOS or Android, often distributed through an app store. It can be built natively for each platform or with a cross-platform approach. Here, the decision is about the first user experience and distribution route, rather than a particular framework.
2. Compare the routes to your first users.
Use these starting points to discuss the trade-offs. They are prompts for a decision, not guarantees about cost or capability.
Scroll sideways to compare both options.
| Question | Web app | Installed mobile app |
|---|---|---|
| How do users arrive? | A link can take them straight into a browser flow. | Users usually install the app before their first task. |
| Where is the work done? | Can support phone and desktop workflows through responsive layouts. | Designed around the selected mobile operating systems and devices. |
| What must be tested? | Target browsers, screen sizes, permissions, and any installation flow. | Target devices, operating-system versions, permissions, and the release process. |
| How are changes delivered? | A new web release can reach users without a store update; caching still needs care. | Store releases and user adoption of updates are part of the plan. |
3. Check device features one by one.
“Needs a camera” does not automatically mean “needs a native app”. Web apps can request camera and microphone access in the browser; this requires a secure context, such as HTTPS, and the user’s permission. The question is whether the exact capture flow works reliably on your users’ devices.
Notifications need the same care. Apple supports Web Push for Home Screen web apps on iOS and iPadOS 16.4 or later. The user must add the web app to their Home Screen and grant notification permission; it is not the same journey as opening an ordinary browser tab. Do not promise notification delivery simply because a user has visited a site.
For Bluetooth hardware, location tracking, background tasks, or demanding media processing, prototype the specific requirement. Check browser and operating-system support, permissions, and what happens when the app is no longer in the foreground. An installed app also has platform limits.
4. Define what “offline” needs to do.
A progressive web app (PWA) can offer installation and offline features in supported browsers. Those features must be built and tested; an install icon does not make server-dependent tasks work without a connection. Browser storage also has limits and can be cleared.
Be specific: should users read previously loaded material, save a draft, or create records that sync later? Decide how the interface shows pending work, handles conflicting edits, and recovers when connectivity returns. An installed mobile app needs these decisions too.
5. Budget for distribution and maintenance.
For a first experiment, compare the complete scope on each platform: interface, backend, integrations, testing, release, and support. A web app may reduce the installation barrier, but it is not automatically cheaper. A complex browser editor can need more work than a focused mobile tool.
Store distribution adds submission and review work. Apple’s guidelines include minimum-functionality requirements, so repackaging a website is not a guaranteed route to approval. Plan the release requirements for the stores you intend to use.
Shared code can reduce duplication across iOS and Android, but device testing and platform-specific work remain. Discuss who will maintain dependencies, fix issues, manage store or hosting accounts, and support users after launch.
6. Choose the first platform for one complete journey.
Consider a hypothetical tutor-booking product. If students arrive through a link, choose a time, and receive confirmation, a responsive web app is a reasonable first option to test. Requiring an installation could add an unnecessary step for occasional users.
Now consider a hypothetical field-inspection tool used every day on company phones, with photos, offline records, and specialist hardware. An installed mobile app deserves evaluation, alongside a technical test of the required integrations. The decision depends on that workflow, not simply on whether the product uses a camera.
Different roles can also use different interfaces. Students might book on the web while tutors manage a schedule elsewhere. Start with the role and task you need to learn about first; add a second platform when a concrete need justifies the work.
7. Bring these questions to the scope discussion.
Before choosing a platform with a developer, prepare a short brief:
- Who will use the first release, on which devices, and in what setting?
- How will they discover the product, and is installation a reasonable expectation?
- Which device capabilities are essential, and which still need a technical test?
- What must work offline or while the app is in the background?
- What information needs to move between devices or different user roles?
- Who will manage release, maintenance, support, and ongoing service costs?
Write down the platform choice, the assumptions behind it, and the evidence that would change your mind. You can revisit the decision after the first users have tried the core journey.