Read the current process
Choose the delivery model around a task that must work, rather than a preference for an app-store icon. Who uses the product, on which devices, with what connectivity? A customer opening an occasional quote link and a technician working underground have different constraints even if both need a mobile interface.
A boundary worth keeping
A responsive web application offers access through a URL. A PWA adds web-based installation and offline patterns where supported; MDN documents these capabilities and their implementation. A native application may suit deeper device integration, but also brings platform delivery and update work. Treat support for your required hardware and background behaviour as something to demonstrate on target devices.
Follow one real task
Imagine inspectors recording equipment condition in areas with poor reception. Test the central task early: open an assigned inspection, save observations without a connection, restart the device, and synchronize later. Decide how a server-side reassignment or a second person's edit is reconciled. A cached screen without durable edits is not a working offline process. If this task works reliably in the chosen web environment, native delivery may not be necessary.
Protect the exceptions
Avoid making offline, notifications or device access a checkbox without naming the supported environment. Do not make an occasional customer install software just to read a document. Include login expiry, local data removal, app updates and permission denial in the prototype. A choice that reduces initial development but makes the essential field task unreliable is not a saving.
Use a capability rehearsal to reduce the uncertainty
For the inspection example, write a short capability brief before comparing implementation estimates. Name the actual devices, operating systems, browsers and accessories the field team uses. Describe the required task in observable terms: read an assigned job, capture a photograph, retain the draft after closing the application and submit it when a connection returns. Avoid requirements such as full offline support that leave both the data and the duration unspecified.
Build the smallest proof that exercises those uncertain capabilities together. A camera demonstration on its own does not prove that photographs survive an interrupted submission. A local draft that survives a refresh does not prove it can be matched safely to a reassigned inspection. Define conflict choices explicitly: preserve both observations for review, merge fields under agreed rules or require a person to choose. The choice should follow the business meaning of the data rather than whichever value arrived last.
Compare the total operating arrangement after the proof. Include device enrollment, distribution, permission setup, updates and support when an employee replaces a phone. If a native app is needed for field capture, the office team may still use a web interface for review; every role does not need the same delivery model. Conversely, adding installation to a web application is only worthwhile when it helps a real usage pattern. Keep a fallback for unsupported environments and explain its limits. Document the tested combinations and repeat the relevant checks when the application or supported device environment changes.
A platform decision table
| Requirement | Decision evidence |
|---|---|
| Occasional customer access | A direct link completes the task without unnecessary setup; installation is not imposed solely to imitate another product. |
| Offline field capture | Draft and attachments survive the agreed interruption and restart, with visible synchronization and conflict handling. |
| Specialized device integration | The required accessory is demonstrated on the target environment, including denied permission and disconnected hardware. |
| Mixed office and field work | The chosen interfaces share consistent records and permissions even when their delivery models differ. |
Before deciding
What must still work without a connection? Which device capability is indispensable? How will users discover, install and update the product? Bring those answers to web-application scoping and build a small technical proof of the most uncertain task before committing to the delivery model.