Understand what the three options mean
A responsive website adapts its interface to different screen sizes and is accessed through a browser. A progressive web app, or PWA, uses web technology with additional app-like behaviour. MDN describes features such as installation and offline operation, with support varying by environment. A native app is built for a particular operating system and its platform interfaces.
These categories do not decide product quality. A website can have accounts and complex workflows. A PWA still needs a well-designed web experience. A native app still needs useful content and reliable services. Distinguish platform choice from implementation choice: a shared mobile framework may produce iOS and Android apps, while leaving platform-specific work to maintain.
Examine how people arrive and why they return
Write down the first three steps of the customer journey. Someone opening a restaurant menu from a shared link may want information immediately. Asking them to install software before reading it creates another step. A technician using a work tool throughout the day may value a dedicated app and persistent local work.
Assess frequency, urgency, and discovery separately. Frequent use can support the case for installation, but it does not automatically require native development. A public website and a specialist staff app can also coexist. Decide which audience each interface serves, then consider whether shared accounts, data, and administration make the combined operating model manageable.
Specify exactly what must work offline
Offline is a set of behaviours to design. List what people must read, create, change, and send without a connection. web.dev explains that offline web data requires storage management, including limits and persistence. Cached pages alone do not define a dependable working process.
For a field inspection tool, specify whether yesterday’s job list remains available, whether a new photo is saved locally, and how an inspector knows a report has reached the server. Design pending, failed, and synced states. Decide how duplicate submissions and conflicting edits are resolved.
Local browser data can be removed, including by the user. Do not treat it as the only copy of important records. Test closing and reopening the app, expired sessions, interrupted uploads, and reconnecting after a long gap. Native apps also need explicit data and synchronisation design; installation does not make a transaction succeed offline.
Test the capability that could change the decision
Replace “needs phone features” with a precise list: capture a photo, read a particular scanner, share a document, or receive a notification. web.dev advises detecting feature support because web capabilities vary across devices and browsers. Check the required behaviour on the actual combinations your audience uses.
Notifications illustrate the importance of details. Apple documents web push for Home Screen web apps on iOS 16.4 or later. That does not mean every visitor in an ordinary browser tab has the same notification experience. Include installation and permission steps in the prototype.
If reliable background work or specialist hardware is central, commission a focused technical experiment before approving the full interface. Test denial of permissions and unavailable features. Prefer a platform only after the essential task works under its real restrictions.
Compare the work after release
Ask for a maintenance plan alongside the build estimate. Websites and PWAs need browser testing, dependency updates, hosting, security work, and content operations. A PWA also needs careful handling of cached versions and offline data. Mobile apps add platform release and compatibility work; shared code does not remove every difference.
Android’s quality guidance calls for current platform compatibility, SDK maintenance, and testing on representative devices. Use this as a reminder to budget for ongoing engineering. Ask who investigates crashes, tests an operating-system update, handles account access, and releases fixes.
Compare approaches over the same period and scope. Include backend services, administration tools, testing devices, support, and ownership of accounts. Avoid universal cost ratios: the complexity of your actual workflow may matter more than the platform label.
Use scenarios to expose the tradeoffs
The following examples are decision exercises, not claims about existing clients:
- A Baghdad consultancy needs service pages, project explanations, and enquiry forms. A responsive website is a plausible starting point because the core journey begins with reading and contacting the team.
- A distributor’s repeat customers browse an order catalogue on phones and laptops. A PWA may fit if the required browser support, installation experience, and offline catalogue behaviour are verified. Stock confirmation still requires a defined server interaction.
- A field team depends on a specific scanner and work continuing when the interface is closed. Evaluate a native app against those exact hardware and background requirements before deciding. A separate web dashboard may suit office staff.
Record a decision you can revisit
Use this checklist to make a reviewable choice:
- 1. Name the primary user task, entry point, and expected frequency of use.
- 2. List supported devices, operating systems, browsers, languages, and accessibility needs.
- 3. Describe the exact offline and device behaviours required, with acceptable fallbacks.
- 4. Prototype the highest-risk requirement on representative real devices.
- 5. Compare initial delivery and ongoing ownership using the same scope.
- 6. Record the choice, its assumptions, and the evidence that would justify changing it.
Your next step
Choose the platform that can reliably complete the user’s task within your operating constraints. Keep the reasoning visible: if customer behaviour or a required capability changes, you should be able to revisit the decision without restarting the product conversation.