Observe the working environment
A field application may be used in a warehouse aisle, a customer’s premises or a vehicle between visits. Watch the task in that setting before choosing a platform. A connection that looks reliable in an office may be intermittent where the work happens.
List the hardware the task needs: camera, barcode scanner, location, notifications or a specialist peripheral. Then record how often each feature is used and whether the user needs it when offline. The combination is more useful than a generic preference for native or web development.
Consider the web when reach matters
A browser-based application can be a practical starting point when users need easy access across devices and the workflow fits the browser’s capabilities. It also makes the path from an invitation link to a first task straightforward.
Confirm the actual browser and operating systems before relying on a device feature. Prototype the critical interaction on those devices. A feature being available somewhere is not the same as it working consistently for your users.
Treat offline work as a product decision
Android’s official offline-first guidance describes a local data source alongside a network source and a strategy for synchronisation. The engineering pattern still needs business decisions: what can be edited without a connection, what happens if two people change the same record, and how a user knows whether an action has reached the server.
A saved draft and a confirmed submission should look different. If the application queues work, show what is waiting and what needs attention. Decide how a failed upload is retried without creating duplicate records.
Plan distribution and maintenance
A mobile application introduces decisions about device support, release distribution and update adoption. A web application introduces its own compatibility and connectivity considerations. Include those ongoing responsibilities in the brief, not just the cost of the first version.
Build a small prototype of the hardest task before committing to the full application. Test it on a typical device, on a weak connection and with the real person performing the task. That evidence makes the platform decision easier to defend.
Choose for the complete workflow
The right choice is the one that reliably supports the work and that the organisation can maintain. Write down the constraints, demonstrate the critical interaction and agree how failures appear to the user. The platform follows from those decisions.