Contents
Start with where and how people will use the product. A browser-based service and an installed mobile application can support different parts of the same journey. The decision becomes clearer when you identify the tasks, devices and operating conditions that matter, then test the capabilities on which the choice depends.
Map the journey and the device context
Describe what users need to do, how often they do it and where they are when they do it. A short task reached from an email may have different access needs from repeated work performed away from a desk. Include administrative users who may need a larger screen or a different workflow.
Identify the devices and environments the first audience actually uses. Record whether devices are personally owned or managed by an organisation, and who can install or configure software. Avoid making the decision from the preferences of the project team alone.
Test the capabilities that could determine the choice
List the required interactions with the device, such as capturing media, receiving notifications or working without a reliable connection. Describe the exact behaviour needed rather than writing a broad requirement such as offline support. Specify what users can read or change and how work should be reconciled after reconnecting.
Check current platform and browser support for the target devices, then build a focused trial for any critical uncertainty. Do not assume that a capability exists everywhere because it works on one development device. Record the tested versions and limitations so the decision remains traceable.
Consider how users first reach the product
Map the steps from invitation or discovery to successful use. For an installed application, account for the installation and account-setup journey. For a browser service, consider sign-in, links and the experience across supported screen sizes. Test the whole sequence with representative users.
If different groups need different surfaces, identify the shared data and business rules behind them. Keep access enforcement in the backend so a change of interface does not change the user's authority. Explain how support will identify which experience the user is working with.
Include distribution and updates in the delivery plan
Identify the distribution route for each audience and the accounts required to operate it. Verify the current requirements of the chosen route when planning the actual release. Name the owner responsible for submissions, configuration and ongoing account administration.
Plan how the backend behaves while users have different application versions or cached resources. Decide which changes can remain compatible and how users are informed when an update is required. Include the testing and support work for those states in the estimate.
Compare the complete scope and operating responsibility
Compare options using the same core journey and acceptance criteria. Include design, implementation, device coverage, accessibility, distribution and maintenance. A smaller initial codebase does not necessarily describe a smaller overall responsibility if it leaves important platform behaviour untested.
Consider the team's ability to maintain the chosen approach and investigate issues on the actual devices. If the product needs both web and mobile surfaces, explain which responsibilities can be shared and which require separate work. Keep those assumptions visible when comparing proposals.
Choose a first release with an explicit review point
Select the approach that meets the most important demonstrated needs of the first audience. Record the evidence supporting it and the capabilities that remain uncertain. If a single requirement drives the decision, resolve it with a focused trial before committing to the wider build.
Review real usage after release. Check whether the chosen access and device assumptions hold and whether another surface would solve a demonstrated problem. Add a platform because the evidence supports it, with its own scope and operating owner.
Compare two access journeys before choosing a platform
A fictional events business needs occasional customers to open a booking from an email and staff to check admissions repeatedly at a venue. For the customer journey, test a responsive browser flow from link to accepted booking. For staff, test the actual venue device, intermittent connection and the required scanning interaction. The two audiences may need different surfaces backed by the same account and booking rules.
Write a decision sheet with entry friction, device capability, disconnected behaviour, update route and support ownership. State the offline rule precisely: may staff read a previously loaded list, record an admission, or both? How is an admission reconciled when another device acted during disconnection? Do not choose an installed app until a critical device or operational requirement justifies it, and do not assume the browser covers that requirement without a trial.
Verify current support on the intended devices and distribution route. Apple’s review guidance is relevant if an iOS app will be submitted, but it does not describe browser compatibility or guarantee approval. Give the chosen first release a review point: observed access and task completion should inform expansion to another surface, rather than an expectation that every product starts with both.
How this relates to Veda Software’s work
Infinity Club has a published connected web and mobile experience with different member, partner and administrative needs. It supports investigating audience-specific surfaces, not a universal platform recommendation.