“We need an app” is a useful beginning to a conversation, but it is not yet a product brief. A customer checking your opening hours has a different need from a driver recording activity throughout the day. Both may use a phone. That does not automatically mean both need the same delivery format.
Before choosing a mobile app, a web application or a conventional website, describe the repeated task. Who performs it? Where are they? What happens when the connection is weak? What would make them return? Those answers are more useful than choosing the technology because it looks impressive in a pitch.
An occasional visitor or a daily user?
A web link can be shared in a message, opened from search or followed from a social profile. That can suit a business whose immediate goal is explaining an offer, presenting a catalogue or receiving enquiries. Asking someone to install an app introduces another decision before they reach that value.
For an existing customer who uses a service repeatedly, installation may make more sense. The question is whether the repeat use is real enough to justify the additional product, release and support responsibilities. A branded icon alone is a weak reason to create them.
What does the phone need to do?
Write down the device features and behaviour the service requires. These might include camera use, reliable offline work, notifications, background activity or integration with other applications. Then verify those requirements on the actual operating systems and browsers your audience uses. Avoid making the decision from a generic feature comparison.
MDN’s progressive web app guidance describes how web applications can support installation and offline experiences using web technologies. These capabilities require deliberate implementation, and support varies across environments. A responsive page does not automatically become a dependable offline application because it has been added to a home screen.
The cost continues after the first build.
The initial build is one part of the decision. Consider updates, testing, store distribution where applicable, account recovery, support and the back-end services shared by all interfaces. If the web and mobile experiences show the same records, someone must define how those records remain consistent.
A useful proposal should explain what each interface is responsible for. It should also identify what can be shared and what needs separate work. This helps avoid paying for duplicate features that create more maintenance without improving the user’s task.
Choose a first release you can learn from.
For some businesses, a strong mobile website is the sensible first investment. For others, the operational requirements justify a dedicated app from the beginning. A staged approach can also work: prove the central workflow, observe real usage and expand once the reason is clear.
Ask the person recommending an app to name the requirement that makes it necessary. Then ask what would be lost by starting on the web. If the answer is a critical daily task or a verified device requirement, there may be a strong case. If it is mainly a preference for having an app, the business still has a decision to work through.
Read further
Original sources behind the technical guidance in this article.