The best starting point is the place your customers already expect to do the task. A mobile app adds little if someone only needs to make an occasional enquiry. A website may be insufficient if the core experience depends on sustained use of device features. Choose the format after defining the behaviour.
Distinguish a website from a web app
A website usually helps people understand an offer and take a next step. A web app lets them complete ongoing work: manage bookings, collaborate, process documents or run a business workflow. Both can share a domain, but their content, permissions and testing needs are different.
If your immediate goal is explaining a service and collecting qualified enquiries, a focused website may be the right first investment. If users need accounts, stored work and repeated interactions, plan the product experience as well as the marketing pages.
Map the task to the device
Write down where the task happens, how often it happens and what the device must do. A field worker capturing information on unreliable connections has different needs from an analyst reviewing a large table at a desk.
Browser capabilities and mobile platform rules change. Validate the exact camera, notification, background processing or offline behaviour you need on the devices your audience uses. Do not choose a platform based only on a feature appearing in a comparison chart.
Consider the first visit and the hundredth
A link gives a web experience a direct route from search, email or a shared message. An installed app asks for more commitment, which can make sense when the product earns a recurring place in someone’s day.
Sketch both acquisition and repeat use. How does someone discover the product? What brings them back? Where do they resume an unfinished task? These questions often clarify the choice more quickly than a debate about frameworks.
Budget for the whole product
Compare implementation, testing, release management and ongoing maintenance. If you need a public website, an administration tool and two mobile platforms, make all of those visible in the scope. A shared codebase can reduce duplication, but it does not remove device-specific testing.
Account recovery, support, analytics and content updates also need an owner. The first version should fit the team that will operate it, not just the team that will build it.
Prototype the uncertain part
Before committing to a full build, test the interaction or technical dependency that could change the decision. A small working prototype on real devices is useful evidence. Start with one platform when it serves the core task, then expand when user behaviour gives you a reason.