Website, web app or mobile app: which does your business need?

Start with the task and the people

Describe one useful action in plain language: find a service and enquire, check a project document, approve a request or record a site visit. Identify who performs it, how often, where they work and which system holds the current information.

Before commissioning software, check whether an existing product can support the process with configuration or a supported connection. Custom work becomes easier to justify when you can point to a specific gap and explain how people will use the result.

Separate the three buying decisions

These are starting points, not exclusive categories. A public website may lead to a separate customer portal. A business app may work well in a mobile browser without being distributed through an app store. A phone mock-up alone does not tell you how an application is delivered.

Our website service focuses on the public customer journey. Our business application service starts with users, processes and access. Store-distributed app delivery requires its own confirmed scope and delivery arrangements; this comparison is not a promise that every approach is included in a website project.

Test device and connectivity assumptions

Write the requirement as an observable task rather than a technology label. “A surveyor can view today's visit details when a connection drops” is more useful than “we need offline mode”. Specify which information must remain available, which changes can be made and how conflicts are resolved when connectivity returns.

Progressive web apps use web technologies and can provide capabilities such as installation and offline behaviour. The actual experience depends on implementation, browser and device support. Use MDN's PWA documentation as a starting point, then test the exact tasks on the devices your users have. Do not assume every browser-based or installed app automatically works offline.

For camera, location, notifications or background activity, ask for a small technical demonstration before committing to the architecture. Record permissions, fallback behaviour and what the user sees if a capability is unavailable. A feature list is not a substitute for that test.

Plan information ownership and permissions

List the records the app needs, the system that owns each one and the roles allowed to read or change them. Customers should only see their own material; staff access should reflect their responsibilities. Include invitations, lost access, departing staff and exports in the brief, not only the main happy path.

A client-portal brief can help narrow the first release to a useful set of documents, updates and decisions. Where information already lives in another tool, assess the supported integration options before creating a second source of truth.

Compare the whole operating commitment

Ask who will handle releases, user support, security updates, licences and changes in connected systems. For a distributed app, also clarify who controls distribution accounts and is responsible for submission, review feedback and future platform updates. Those responsibilities need to be confirmed with the delivery partner.

Compare one-off work, recurring subscriptions and usage-based charges using the same expected user tasks. There is no universal price ratio between a website and an app. A small portal and a multi-role operational system can have very different requirements even though both run in a browser.

Avoid committing a full feature list before testing the core workflow. A prototype can reveal whether the labels, steps and handovers make sense; a technical trial can answer a specific compatibility question. Neither should be presented as a production-ready system.

Copy this decision worksheet

• Users and task: who needs to do what, and how frequently?
• Current process: where does the information live and what causes the observed problem?
• Existing tools: what can be configured or connected before custom development?
• Working conditions: devices, connectivity, accessibility and support needs.
• Access: who can view, change, approve and export each record?
• Feasibility questions: which requirements need a test before a build approach is chosen?
• First release: the smallest complete workflow and what is deliberately left for later.
• Operation: account ownership, support, ongoing costs and release responsibilities.
• Acceptance: the task a representative user must complete, including a failure or interrupted connection.

Work through a fictional example

A landscaping business wants crews to see the current job brief, record photographs and flag an access problem. The first investigation is whether its existing job system can support that workflow. If it cannot, a browser-based workspace may be worth testing. If a specific offline or device requirement remains unresolved, evaluate that separately before choosing a mobile delivery approach.

The crew handover guide gives the operational detail behind this example. The decision is not “apps look more professional”; it is whether the proposed system helps a real user complete a useful task and whether the business can operate it afterwards.