Where does the user's task actually happen?
When considering web application development, define the user and task first. Who needs to complete what, using which information and under which conditions? A browser-based panel and an installed application might solve the same business problem, but the working environment changes the experience required.
On a desktop, document comparison, wide tables and detailed forms may be important. Someone on the move may need one-handed use, a camera, location or operation with interrupted connectivity. “Our competitor has an app” does not explain these requirements. Consider the urgency of the task and the consequence of a mistake alongside usage frequency.
For example, an office team approving orders and a warehouse team counting inventory may use the same underlying data. One might need a web panel while the other needs a phone-oriented workflow. This is an illustrative design scenario, not a measured Prix project outcome. Verify which surface is necessary first rather than launching both by default.
How do access and discovery differ across web, PWA and mobile?
A PWA approach can add installation and selected app-like capabilities to a web experience under supported conditions. It is not another name for a native application behaving identically in every browser. Opening a link and installing something for repeated use are separate customer behaviours.
The web can be useful for shared links and first access. It can still create friction through login, slow connections or complicated registration. An installed mobile app asks users to complete installation and permission steps. The product should offer a benefit that makes those steps worthwhile.
Store presence is not an automatic discovery or usage guarantee. Plan where customers encounter the product, how they reach the first useful action and why they return. Separate public information intended for search discovery from private application screens requiring authentication.
This distinction can support a combined approach later. A public website may introduce the service while a mobile app performs a specific repeat task. That combination should follow demonstrated requirements, not the assumption that every business needs every channel.
| Option | Potential fit | Evidence needed |
|---|---|---|
| Web | Link access, desktop work or occasional tasks | Browser, authentication and critical-task usability |
| PWA | Web access with selected app-like capabilities | Target device, installation conditions and API support |
| Mobile | Repeat use or a mandatory device workflow | Installation value, permissions, store and version process |
FROM READING TO A NEXT STEP
Choose the first product surface using evidence
Share the main user, critical task and mandatory device capabilities. We can define a practical decision scope for web, PWA and mobile.
How should device capabilities and offline work be verified?
A mobile approach such as React Native can be evaluated for device integration. Some requirements may also be achievable with web APIs in supported environments. Merely listing camera, notifications or location is insufficient: the precise behaviour must work on the devices and operating systems the audience uses.
A camera requirement might mean selecting a photograph, continuous scanning or integration with another device. These create different scopes. Notifications do not imply delivery under every condition. User permission, operating-system behaviour and application state still matter. Define an alternative when permission is declined or the capability is unavailable.
For offline use, distinguish “the screen opens” from “the task can be completed”. Reading an earlier record, saving new information and resolving conflicts once connectivity returns are separate requirements. Plan what happens when two people change the same record or the device removes local data.
These rules require development and testing on web and mobile alike. Selecting an installed app does not automatically solve synchronisation, just as labelling a web product a PWA does not guarantee the mandatory offline workflow.
What changes in distribution, updates and maintenance?
Mobile application maintenance involves store requirements, operating-system changes, device tests and versions still present on customer devices. Review access, functional accounts and a working backend need preparation. Having a store process does not guarantee acceptance or release on a specific date.
Web updates can be deployed through the server, but caches, browser differences and active sessions may retain old behaviour. Hosting, security updates, access management and monitoring remain necessary. Do not describe web as maintenance-free or mobile as a product with only an initial development bill.
Compare the same capabilities and support period when discussing budget. A basic web form and an offline mobile data-collection workflow are different scopes. A cross-platform framework can reduce some repeated implementation, but platform-specific tests and integrations still need ownership.
Release planning should also consider backwards compatibility. Customers do not necessarily update an installed app immediately, and an open browser session may outlive a backend change. Critical contracts should be handled deliberately rather than assuming every user receives the new version at once.
Which surface should you build first?
Choose a first web release or mobile experience using three pieces of evidence: the main task is usable, the mandatory capability works and the team can maintain it. Reduce uncertainty with a focused trial of the riskiest feature instead of building the entire product twice.
Web first and mobile later can be sensible. Mobile first followed by an operational web panel can also be sensible. The order follows the user's need and the business model. Use completion, support and repeat-use evidence from the first surface to assess the second investment.
Document the decision in a concise scope note: user, task, supported devices, necessary capability, excluded requirements and acceptance test. Record which change in requirements would reopen the decision.
This gives a later discussion something concrete to examine. A new feature may justify another surface; it should not erase the original reasoning simply because a different framework has become popular with the team.
Choose the task
Define the primary user, the required action and the working environment.
Test the risk
Verify the necessary device or offline behaviour with a focused prototype on target devices.
Release the first surface
Assign acceptance and maintenance ownership, then assess expansion from actual usage.
BEFORE YOU DECIDE
Frequently asked questions
Is a PWA the same as a mobile app?
No. It adds selected capabilities to a web experience, with differences across browsers, devices and installation conditions. Test the mandatory task in the intended environment.
Can a web app use a camera or notifications?
Some functions are possible with supported web APIs and permissions. Do not assume the precise behaviour works on every target device; verify each necessary capability.
Can we build web first and mobile later?
Yes. API and data planning can help prepare the foundation. Mobile interaction, permissions, distribution and tests still need their own scope.
Does an installed mobile app automatically work offline?
No. Decide which data is available, how new work is saved and how it synchronises when connectivity returns. Installation does not implement those business rules.
Which option is cheaper and faster?
That depends on scope. Compare equivalent features, platforms, integrations, acceptance tests and support periods instead of applying a universal saving or timeline.
Do we need both at the same time?
Only when both have demonstrated needs. Otherwise begin with the primary task and use real usage evidence to evaluate a second channel.
LET’S DEFINE THE SCOPE
Choose the first product surface using evidence
Share the main user, critical task and mandatory device capabilities. We can define a practical decision scope for web, PWA and mobile.
Review my product surfaces