Where and how will people use the product?
Start with real situations: where the user is when they open the product, how often they come back and which devices they use. An engineer on a building site with a weak signal and an office manager at a desktop have very different needs, even when they work with the same data.
Record each requirement with a concrete example. Not just “camera access”, but “photograph a meter reading and attach it to the job”. Not just “works offline”, but “fill in an inspection without a connection and send it when the signal returns”. The same applies to notifications and accessibility: describe the situation, not the feature name.
Many capabilities depend on the browser, the operating system and permission settings, and support differs between platforms. Check the behaviour you need on the devices and versions you plan to support. Choosing a platform from a general comparison table, without trying the crucial task, is how projects end up rebuilding the app later.
What does each option mean for release and support?
A web app and an app distributed through stores live by different rules. You can update a web release whenever you choose. A store app goes through review, and users install updates on their own schedule, so you may have to support several versions at once. Store accounts, app signing and listings add their own work as well. That is why web application development and mobile app development are planned differently from day one.
Think about how people will find and install the product, too. A web app opens from a link and needs no installation, which helps when people use it only occasionally. A store app is easier to come back to from the home screen and can make fuller use of device features, but the user has to install it first.
Some things are the same either way: you still need user sign-in, a server side with a clear owner, testing and monitoring. A shared codebase for several platforms can remove some duplication, but device-specific work remains, from permission prompts to the way the on-screen keyboard behaves.
So estimate the project around acceptance criteria and integrations. No technology choice makes every requirement cheap, and an estimate built on that assumption usually grows during development.
Which interaction should you prove first?
Before committing to the full scope, build a prototype of the hardest behaviour the product must have. For field work, that might be losing the connection and syncing afterwards without losing data. For a consumer product, it might be the first sign-in and setup, followed by the first completed task.
Test the prototype with typical users on typical devices, not only on the developers’ latest phones. Then write down the platform decision, the reasons for it and the constraints that remain, so the decision can be revisited if circumstances change.
Keep the practical questions in the delivery brief too: who owns the code and accounts, how the source will be handed over and what maintenance is expected after launch. They affect the choice of platform just as much as the feature list does.
Checklist: choosing a platform
- Describe where, how often and on which devices people will use the product.
- Write device requirements as concrete tasks with examples.
- Check critical capabilities on the target devices and versions.
- Compare release, testing and maintenance work for each option.
- Prototype the riskiest interaction before expanding the scope.
Example: a product for field engineers
A field-service product needs to photograph equipment and recover reliably after the connection drops. Before choosing between a web and a mobile app, the team tests exactly these two tasks on the phones the engineers carry.
The managers’ dashboard is a different case: it is used at a desk, so it can have its own web interface. Both interfaces work with the same controlled server-side records, so the choice for one does not dictate the choice for the other.
