“We need an app” can mean several things: software people open through a link, something they install on a phone, or both. Before deciding, I want to understand the task and where people will do it. That gives us a better basis for choosing how to deliver the product.
A customer booking occasionally from a search result has different needs from a field worker recording information throughout the day. Use those situations to decide what matters, then test the capabilities the product depends on.
Start with the task and the route into it
Describe how someone first finds the product, how often they return and which device they use. An account manager reviewing a long report may prefer a laptop. A technician taking photos at a job needs a phone-friendly workflow. One business can have both audiences.
How will people find and open the product: a search result, an invitation, a QR code or an app store?
Is the task occasional, daily or part of a continuous working session?
What must work when the connection is weak or unavailable?
Which device features are essential to completing the task?
When a web app is a good starting point
A web app runs in a browser and can be shared through a link. It can suit account portals, booking systems, dashboards and many other workflows. Responsive design adapts the interface to different screen sizes, but we still need to test the actual tasks on those screens.
For example, a supplier portal might let customers place orders on a phone while staff manage them on a desktop. A shared web application could serve both groups, with different views and permissions. An app-store listing would need a specific benefit to justify adding it to the first release.
What an installable web app can offer
A progressive web app, or PWA, uses web technologies and can offer an installed experience on supported devices. Offline behaviour, notifications and other capabilities need deliberate implementation and compatibility checks. An icon on the home screen does not make anything work offline.
For background on that approach, see MDN’s introduction to progressive web apps. For your project, I would test the required capabilities on the devices and browsers your customers use, then define a fallback for anything unavailable.
When a mobile app deserves its own scope
A mobile app can be appropriate when the workflow depends on deeper device integration, an installed experience or a particular distribution channel. Write down those needs precisely. “Uses the camera” alone is too broad; the required capture process, permissions and supported devices are what we need to evaluate.
An inspection tool might need to keep a draft report on the device during a site visit and upload photos later. The decision should include how drafts survive interruptions, how syncing behaves and what happens when two people edit the same record. Those are product decisions, and an installed app still needs them made.
Store releases also need preparation: accounts, listings, review requirements and a process for maintaining released versions. We should account for that work when comparing the options. Approval and timing remain subject to the relevant store’s review.
Shared code still needs platform testing
Some approaches share code between platforms or extend an existing web product. That can help reuse work, but the amount depends on the application and its requirements. I would review the existing code before promising that a web app can simply become a mobile app.
The server and database may serve both web and mobile interfaces. Each interface still needs appropriate navigation, input handling, permissions and testing. The goal is a coherent product across the devices people actually use.
Choose the next release around evidence
You can start with one channel and add another when there is a clear reason. If the uncertain part is a device capability, test that capability early. If the uncertain part is whether customers need the workflow, test the workflow with representative users before expanding its distribution.
Our main users and their devices are: …
Their most important task is: …
They reach the product through: …
The capabilities we must verify are: …
We would add another platform when: …
Send that context with your project brief. I can help compare the options against the work you need done and plan the first useful release.