“We need an app” often means something more specific: customers should book without calling, technicians should record work on site, or managers should approve requests away from their desks. These are different products, even if they all run on a phone.
Before choosing web, cross-platform or native development, describe who uses the product, how often they return and what must still work when the connection is poor. The right option is the one that reliably supports those tasks with a sustainable operating cost.
Start with frequency and context
An occasional customer may prefer opening a booking link to installing an application. A technician using the same tool throughout the day may value quick access, predictable offline behaviour and support for a dedicated scanner. Neither preference determines the technology alone, but both shape the first prototype.
Interview users where the work happens. Note whether they wear gloves, share devices, move between buildings or need to recover interrupted tasks. For an internal product, list the actual phone models and operating-system versions the company supports. For a public product, use evidence about the audience rather than the team’s own devices.
Write one measurable objective, such as completing a site report without retyping it at the office. That is more useful than asking for “a modern mobile experience.”
Understand what each delivery option changes
A responsive web app is accessible through a browser and a link. It can be a strong starting point for enquiries, customer portals and occasional workflows. A progressive web app can add installation and offline behaviour, but these capabilities require implementation and device testing. MDN explains the role of service workers in offline and background operation.
Cross-platform development can share substantial application code across mobile platforms. It still needs platform-specific testing, release management and sometimes native modules. Treat “one codebase” as an implementation strategy, not a promise that every screen or device integration requires no separate work.
Native development gives a team direct access to a platform’s development tools and APIs. It may be appropriate when a critical workflow depends heavily on platform behaviour or specialized hardware. The comparison should include the effort of maintaining the supported platforms, not just building the first release.
Instead of scoring options against a long generic feature list, identify the two or three requirements that could rule an option out. Test those first.
Design offline work as a complete workflow
Opening a cached screen is different from safely saving a completed job. An offline workflow must explain where data is stored, what users can change, how they see pending work and what happens when two people edit the same record. Android’s offline-first architecture guidance discusses local data, synchronization and conflict handling.
Consider an illustrative field-service app. A technician opens a job, loses connectivity, adds three photos and records completion. Meanwhile, the office changes the appointment. When the phone reconnects, simply keeping the last update could erase an important change.
For that workflow, specify the following before estimating development:
- The job details available before the technician goes offline.
- The information that can be recorded locally and its visible save status.
- Whether photos wait for a suitable connection and how interrupted uploads resume.
- Which changes can merge automatically and which need a person’s decision.
- What the user sees if a login expires before synchronization finishes.
The prototype should demonstrate these states. A native app with no synchronization design can lose work just as a poorly designed web app can.
Prototype the riskiest device capability
If scanning is essential, test real labels under the lighting and movement of the workplace. If location is essential, define the required accuracy and whether the task needs foreground or background access. If notifications matter, define what happens when the user declines them.
Avoid promising identical behaviour across every device before testing. Build a small capability matrix covering the supported devices, required permissions and fallback route. Where a capability is unavailable, the product should explain the next useful action rather than leaving a disabled control with no context.
A short prototype focused on one uncertain integration can prevent much more expensive rework after the rest of the interface is built.
Compare the full release and support cycle
Ask what a routine update involves, who handles store submissions when applicable and how old application versions interact with a changing backend. Include crash investigation, support requests, accessibility checks and operating-system updates in the maintenance discussion.
For acceptance, use real tasks: complete a booking, resume an interrupted report and correct an input mistake. Measure completion and errors as well as speed. A visually polished screen is not sufficient if the user needs a colleague to finish the task.
The final choice should be explainable in a short decision record: audience, essential capabilities, prototype results, supported devices and operating responsibility. Our mobile application service can validate those constraints, while web development may cover a simpler first version. Describe your main mobile workflow and we can identify what to test first.