A business can need a mobile-friendly product without needing a downloadable mobile app. Equally, a responsive website can look convincing in a pitch while failing the repeated, device-specific task that makes the product useful. The first platform decision should follow the user journey, not a preference for a particular technology.
This guide is for teams deciding what to commission before asking for design or development estimates. My recommendation is to identify one valuable end-to-end task, document its constraints and test the riskiest assumption. A platform comparison only becomes useful once those facts are visible.
Separate the three options before comparing them
A web app is accessed through a browser. A progressive web app, or PWA, builds on web technology with capabilities such as installation and a deliberately designed offline experience. A platform-specific app is built for an operating system and can use its SDK and integrations. MDN explains these distinctions; none of the labels guarantees product quality.
The PWA option is worth evaluating rather than treating the choice as website versus native app. Installation and device capabilities vary across browsers and operating systems. Verify the exact workflow on the devices your audience uses instead of assuming that a capability demonstrated on one phone will behave identically everywhere.
Start with the moment of use
Imagine a customer who receives a booking link once a month. Asking that person to install an app may add a step before any value is visible. Now imagine a field team completing the same inspection throughout the working day. Fast repeat access, interruptions, camera use and unreliable connectivity may matter more than the first-visit journey. These are hypothetical scenarios, not a rule that every booking product belongs on the web or every field tool must be native.
- How does the user first discover and open the product?
- How often do they return, and which task do they repeat?
- Are they using a phone, a desktop workstation or both?
- Which interruptions, permissions or connection failures are normal?
- What would make an installation step worthwhile to the user?
Make device requirements concrete
A requirement such as 'works offline' is too broad for an estimate. Does the user only need to read yesterday's records, create a new draft, attach photographs or resolve conflicting edits after reconnecting? Each answer changes the design, storage and engineering work. The same discipline applies to notifications, location, file access and background activity.
Write a short acceptance scenario for every must-have capability. For example: a worker saves a draft without signal, sees that it is not yet synced, reconnects and receives an unambiguous confirmation. Ask the proposed delivery partner to demonstrate that scenario on representative devices before committing to a platform.
Compare the whole release, not just screen development
A credible scope includes authentication, content or administration tools, integrations, accessibility, testing, analytics, deployment, support and future changes. The interface is only part of that work. A shared codebase can still need platform-specific QA; a native app can still depend on a substantial shared backend. Neither 'web is always cheaper' nor 'native always performs better' is a useful blanket promise.
- Ask which platforms and device versions the estimate actually covers.
- Identify who owns backend services, accounts, source files and release access.
- Separate first-release work from maintenance and ongoing operating costs.
- Ask how updates, error reporting and support will work after launch.
- Agree on the acceptance criteria for the complete user journey, not a screen count.
Use a prototype to choose what to build first
Before funding two complete clients, test the primary workflow with realistic content. A prototype can expose confusing decisions, missing states and an unnecessary installation step. It cannot by itself prove offline reliability or a device integration; pair interaction testing with a small technical proof where the risk is technical.
Record the decision in one page: target audience, first-use path, repeated task, essential device features, known constraints, preferred first platform and the evidence that would change the choice. This makes proposals comparable and prevents the team from debating a technology preference after the scope is already priced.
A practical decision rule
Consider a web-first release when direct links, mixed screen sizes and low-friction first access are central to the task. Evaluate a PWA when repeat access or offline behaviour may help and the required browser support is demonstrable. Evaluate a platform-specific app when the product depends on capabilities or interaction behaviour that your tested web approach cannot reliably provide. Keep these as hypotheses to validate, not universal answers.
The strongest platform decision is the one your team can explain using real user needs and tested constraints.
If the mobile journey needs definition before engineering begins, explore the product design and prototyping scope. Mobile app product design ↗
For a browser-based business workflow, start with the software discovery and interface delivery approach. Custom software design and development ↗
Share the audience, one important task and any device constraints you already know. We can use those facts to discuss a focused first release. Discuss your app idea ↗
