Decision guide / Digital products
Website, web app, or mobile app?
Compare three delivery routes by the job people need to complete, the audience that must reach it, the device context and the responsibility the business can sustain.
Direct answer
Which should you build?
Choose a content-led website when the main job is to help a broad audience discover, understand and contact or buy from the business through a browser. Choose a web application when signed-in users must complete repeatable workflows, manage data or collaborate. Consider an installed mobile application when frequent use, meaningful offline operation, device capabilities or timely app notifications are central to the service. These are starting routes, not universal rules: one product can combine them, and the right sequence depends on evidence, constraints and ongoing ownership.
01 / Frame the choice
Begin with the user job, not the format.
"We need an app" describes a container. A useful brief describes the person, situation, action, outcome and business responsibility behind it.
Write the most important job as a sentence: "When [situation], [audience] needs to [action] so that [outcome]." Then list where that job happens, how often it happens, what information it needs and what failure would cost the user or organization.
Six questions that change the route
- Job: is the core outcome learning, enquiring, purchasing, recording, approving, coordinating or operating?
- Audience: must anyone reach it immediately, or is access limited to known customers, staff, partners or members?
- Frequency: will someone visit occasionally from search, or return daily as part of a routine?
- Context: which devices, networks, locations and accessibility needs shape the task?
- Capabilities: does the job truly depend on camera, location, background activity, secure device storage, notifications or robust offline use?
- Ownership: can the organization support accounts, data, releases, app-store operations, integrations and user support after launch?
A modern website can include calculators, accounts and transactions. A web app can contain public marketing pages. A mobile app can be a companion to a browser service. Define boundaries through required journeys and system responsibilities rather than labels alone.
02 / Side-by-side
Compare the likely starting points.
The table identifies common patterns. It is a discussion aid, not a verdict for every project.
| Decision area | Content-led website | Workflow-rich web app | Installed or companion mobile app |
|---|---|---|---|
| Primary job | Explain, publish, attract, compare, enquire or transact through broadly accessible pages. | Let authenticated users create, update, approve, coordinate or analyse information through connected workflows. | Support a repeat task where the phone or tablet is the working environment, often using device or offline capabilities. |
| Typical audience | Prospects, customers, applicants, readers or communities who may arrive without an account. | Customers, staff, suppliers, members or partners with defined roles and permissions. | Known users willing to install and update software because repeat value justifies the commitment. |
| Reach and access | A link opens in a browser and public pages can be discovered and shared. | A link opens in a browser; public entry pages and private workspaces can coexist. | Usually requires store discovery or a direct installation path, followed by operating-system permissions and updates. |
| Device and offline | Responsive browser access is the default; limited caching may be possible. | Responsive browser workflows can support several devices; deep offline synchronization adds significant design and engineering work. | Can use supported device APIs and local storage more directly; reliable offline work still requires explicit conflict and sync rules. |
| Core complexity | Content structure, editorial workflow, conversion paths, search visibility, performance and maintainable publishing. | Roles, permissions, state changes, validation, data models, integrations, auditability, recovery and support. | Platform behaviour, permissions, device variation, release review, offline data, synchronization, privacy and store operations. |
| Likely starting route | When people first need to find, trust and understand the offer. | When the differentiating value is the workflow itself and browser delivery fits the context. | When evidence shows installed, device-aware or offline use materially improves an important repeat job. |
| Ongoing ownership | Content governance, hosting, updates, analytics, accessibility and search maintenance. | All website responsibilities plus user administration, data quality, application monitoring, integrations and operational support. | All product responsibilities plus store accounts, platform releases, permission changes, device testing and adoption support. |
03 / Content-led website
Best when reach and understanding lead.
A website gives people a low-friction route from a link or search result to useful content, a decision and a next action.
Choose this route when the product's most important work is public: explaining services, publishing knowledge, presenting a catalogue, building confidence, capturing an enquiry, accepting a straightforward booking or enabling a purchase. Content architecture, writing and performance are product features because they determine whether people can find and understand the answer.
Public discovery
People arrive through search, shared links, campaigns, referrals or direct navigation without committing to an installation.
Content depth
The service must explain options, evidence, policies, locations, products or expertise through durable pages.
Workflow growth
If users begin managing complex records, permissions or multi-step work, part of the experience may become a web application.
A website is not automatically "simple"
Large catalogues, multilingual publishing, personalization, complex commerce and integrations can make a website technically and operationally substantial. The difference is the center of gravity: public content and accessible journeys lead, even when richer functions support them.
04 / Workflow-rich web app
Best when the product is a system of work.
A web application is usually defined by what signed-in people do with data over time, not by how animated or app-like the interface appears.
Consider a web app when the core value comes from accounts, records, rules and state changes: submitting and reviewing requests, managing inventory, coordinating projects, configuring products, approving work, tracking cases, analysing operations or serving different dashboards to different roles.
Complexity to expose early
- List user roles and the exact records and actions each role can see, create, change, approve, export or delete.
- Draw the lifecycle of important records, including draft, pending, approved, rejected, cancelled, archived and exceptional states.
- Define validation, duplicate prevention, audit history, notifications and recovery when a step or integration fails.
- Name the source of truth for every important data object and decide how conflicts or delayed updates are reconciled.
- Plan authentication, account recovery, administration, privacy, retention and support as part of the product.
- Choose responsive priorities deliberately; a dense desktop workflow may need a different mobile task design rather than simple shrinking.
A web app can serve several device types without asking every user to install software. That advantage does not remove the need for testing, security, operational ownership or careful support for the devices that matter.
05 / Installed mobile app
Best when the device context creates real value.
Installation is a user commitment. Justify it with a repeat job that becomes materially better on the device.
Good reasons may include frequent field work, deliberate offline operation, location-aware tasks, barcode or document capture, device authentication, timely operational notifications, media creation or a companion experience used throughout the day. "Customers use phones" alone is not enough: responsive websites and web apps also run on phones.
Questions before committing
- What repeat value makes a person install, sign in, permit access and keep the app updated?
- Which operating systems, device classes and minimum versions are supported, and who maintains that policy?
- What works without a network, what is stored locally, when does it synchronize and how are conflicting edits resolved?
- Which device permissions are essential, when are they requested and what works if a user declines?
- How will users discover, install, authenticate, update and obtain help with the app?
- Who owns developer accounts, store listings, privacy declarations, signing keys, release review and urgent updates?
A companion app can sit beside a website or web app: the public website explains and acquires, the browser workspace handles broad administration, and the mobile app supports focused work in the field. That division is useful only when each surface has a clear job.
06 / Device and offline reality
Specify contexts, not just screen sizes.
"Mobile-friendly" does not explain whether someone is reading on a sofa, approving on a train or recording work in an area with unreliable connectivity.
| Context | Requirement to define | Route implication |
|---|---|---|
| Occasional public visit | Immediate access, readable content, quick loading and a clear action from a shared or search link. | A responsive website is commonly the lowest-friction starting point. |
| Cross-device office work | Keyboard use, larger views, saved state, roles, exports and reliable browser access. | A web app may fit; validate the important browser and device combinations. |
| Field capture | Camera, scanning, location, attachments, interrupted tasks and uncertain networks. | A focused web app may work; an installed app becomes stronger when device or offline requirements are central. |
| Offline reading | Which content is saved, how fresh it must be and how users know its status. | Limited browser caching or an installed experience may be enough; test the actual content model. |
| Offline editing | Local records, security, queued actions, sync order, duplicates, conflicts and recovery. | Complex on every route. Installed delivery can help but does not solve the data rules automatically. |
| Timely notifications | Business urgency, user consent, fallback channels, quiet periods and action after opening. | Push may support an installed app, but email, SMS or in-product messaging may better match some audiences. |
If the decision depends on offline sync, scanning speed, background behaviour or a complex mobile workflow, test that risk with representative users and devices before treating the route as settled.
07 / Likely starting route
Sequence the smallest coherent product.
The first release should prove an important service loop and create a maintainable foundation, not merely spread a thin feature list across every channel.
A practical decision sequence
- Define the outcome: identify the primary user, job and measurable change.
- Map the complete journey: include discovery, access, the core task, confirmation, support and exception recovery.
- Mark public and private work: separate what anyone needs to discover from what known users need to manage.
- Test context assumptions: validate frequency, devices, connectivity, accessibility and willingness to install.
- Expose system complexity: identify roles, data, integrations, security and operational ownership.
- Select a starting route: choose the surface that delivers the core loop with the least unnecessary dependency.
- Plan the next boundary: record evidence that would justify a companion surface later.
Three illustrative paths
Public first
A specialist service may begin with a content-led website and enquiry path, then add a customer workspace only when ongoing case work justifies accounts.
Workflow first
An internal operations product may begin as a responsive web app, with a small public website explaining access and purpose.
Field companion
A browser system may remain the administrative source while a focused mobile app is added for repeated capture or offline field work.
These examples describe patterns, not prescriptions. Regulation, existing systems, contractual requirements, accessibility needs, team capability or proven user behaviour can change the sequence.
08 / Decision-ready brief
Record evidence and ownership before naming the stack.
A short, concrete brief makes architectural and budget conversations more comparable.
- One primary outcome, the current problem and the consequence of leaving it unchanged.
- Priority audiences, access model and the most important end-to-end journey for each.
- Public content, private data, user roles, approvals and record lifecycles.
- Representative devices, browsers, networks, locations and accessibility requirements.
- Offline, notification, camera, location or other device needs with a reason for each.
- Integrations, data sources, migration needs and the owner of each external dependency.
- Security, privacy, retention, audit and compliance requirements for the real operating context.
- Success signals, analytics boundaries and the evidence that would justify another product surface.
- Content, account administration, support, release, hosting and app-store ownership after launch.
- Known constraints, assumptions to test and decisions that remain open.
Hich Web Development
Planning guidance from the organization.
Published and updated .
09 / Continue
Turn the route into a product brief.
Use the reusable brief template or explore delivery services for the likely starting surface.