Your staff may use phones, but that alone does not tell you whether they need an installed app. Start with the work they must finish, the devices they use and what has to happen when the connection disappears.
Imagine a maintenance company planning a new system. A technician finishes a visit, takes a photo and records what needs replacing. Back at the office, someone checks the visit and arranges the next job. This is a hypothetical example, but it gives us something useful to choose from.
The technician uses a phone. The office uses computers. That tells us the screens need to work on different devices. It still leaves the important questions unanswered: is there reception at the visit, must the photo reach the office immediately, and what happens if someone closes the software halfway through?
Those situations should guide the choice between a web application and an installed app. Choosing the name first leaves the hard decisions for later.
A web application opens in a browser. It can be designed for a phone as well as a large screen. An installed application is software people install on their device. Some web applications can also be installed, so these categories overlap. “Installed” does not tell you how the software was built.
The useful question is whether the proposed version can do the required work on the devices people actually have. For example, taking a photo can be possible in a web application. Google's web application capability guide describes device features available to web apps and the differences in support. The browser, device and permissions matter. A feature working on one phone proves little about the rest of your team's phones.
Be particularly specific about notifications and work that must continue after someone leaves the app. Ask what happens on each intended device, including when permission is refused. An installed alternative also needs its behaviour checked rather than assumed.
Our technician might need to read yesterday's notes in a basement with no reception. Saving a new visit report is a different requirement. Uploading a large photo is another. Decide which of these must work before deciding what to build.
Which information must already be on the phone? Decide what the technician needs to see and how they will know it may be out of date.
Can the visit report and photo wait on the device? Make it clear to the technician whether work is saved there or has reached the office.
What if the office changed the same visit while the phone was offline? Agree which changes should be kept and when a person must decide.
Both browser-based and installed software need deliberate work to support these situations. Installing an app does not settle how it saves data or deals with conflicting changes. Android's offline-first guidance explains these distinctions for Android applications. It is a useful illustration of the work involved, rather than a promise about every platform.
Before commissioning the whole system, ask for a small demonstration of the hardest requirement. For our example, that means using a representative phone to open a visit, lose the connection, save a report and photo, then reconnect. Use invented visit records and photos in a separate test setup, so the trial cannot change a real job or send anything to a customer. Where relevant, compare that task in the intended browser and installed alternative.
Watch what the person sees when something goes wrong. Can they tell whether their report is safe? Can they finish after an interruption? What happens if camera permission is refused? A demonstration on the intended setup gives you something firmer than a feature name in a proposal.
Record the exact device and browser used in the demonstration, what worked and what remains unsupported. Revisit the choice if an essential task still has no workable answer.
Ask how staff or customers will get access, how updates will reach them and who will handle problems. If an app store or a company-managed device system is part of the plan, include the work and requirements for that route. Do not treat acceptance or distribution as automatic.
You may choose a web application, an installed app, or different versions for different jobs. A combined approach can fit the technician and office example, but each version brings work to deliver, update and support. Keep that responsibility visible when comparing proposals.
At LINK-V, we offer custom mobile applications and web applications. When discussing either, bring the situations your software must handle. The useful starting point is what people need to finish, on which devices and under which conditions. Scope, support and commercial terms can then be agreed for that project.
It can be designed to support particular offline tasks. Specify what people must read or save, what stays on the device and what happens when the connection returns. Check the required behaviour on the intended devices and browsers.
Taking photos can be possible in a browser application. Support and permissions depend on the intended setup, so demonstrate the complete photo task on representative devices before choosing.
Phone use alone does not decide it. Choose from the task, device features, connection conditions and how people will receive access and updates. An installed app, a web application or a combined approach may fit.
Last newsletter: making more money from a subscription site or app you already own.
The one before: how to spot AI nonsense from real success stories.
Interested?
Weekly Or just let us know and we'll adjust it for you. Sounds good?
