Many businesses can serve mobile customers well without asking them to install anything. A fast website may be the better product when people visit occasionally, compare options, submit an enquiry, or make an infrequent purchase.
An app becomes easier to justify when the same people return often, need dependable work away from a connection, use the camera or location as part of a task, or benefit from timely account notifications. Even then, someone must own adoption, support, privacy, and releases after launch.
A good mobile website may already be enough
Imagine a homeowner searching for an emergency plumber. They want to understand the service, check the area covered, call, or send a short request. Asking them to visit an app store first adds effort at the worst moment. The same is usually true for an occasional legal enquiry, a property viewing request, a restaurant menu, or a one time purchase.
A responsive website opens from search results, advertisements, email, social posts, and messages. It works across common devices without an installation decision. It can support secure accounts, payments, bookings, forms, maps, and camera access for suitable browser based tasks.
Improve the website first when the current problem is slow pages, confusing navigation, a long form, poor mobile layout, or missed enquiries. Moving the same weak journey into an app will preserve the problem and add store releases to maintain.
- Customers use the service only a few times a year
- Most visitors arrive through search or a shared link
- The main action is reading, calling, booking, buying, or completing a simple form
- The business needs broad access more than repeated personal use
A web app can do more than many buyers expect
A progressive web app is still a website, but it can add app like behaviour such as installation, cached content, offline handling, and push notifications where the browser and platform support the required features. It can be a practical choice when easy link access matters and the workflow does not depend on features the selected browsers cannot provide reliably.
Where it can fit
A membership portal, stock lookup, event schedule, inspection reference, or repeat ordering tool may work well as an installable web experience. The customer can open a link first and choose installation later.
What must be checked
Support for installation, notifications, background work, hardware access, and offline storage varies. Write the required behaviour and test it on the actual iPhone, Android, browser, and managed company devices your users have. Do not approve a progressive web app from a feature list alone.
The field technician who loses the signal
Consider a maintenance technician visiting buildings with unreliable reception. For each job, the technician needs the address, equipment history, safety checklist, photographs, barcode scan, customer signature, time record, and notes.
A useful app can download assigned jobs before travel, save work safely on the device, show what still needs completion, and synchronise when a connection returns. Camera and location access are not decorative features here. They are part of completing and proving the job.
The app still needs a complete operating process. The business must decide what happens when two people edit the same job, a photograph fails to upload, a device is lost, or an offline submission contains an error. The office team needs a visible queue for work that did not synchronise.
Compare the Options
The right choice depends on the job, not on which option sounds more modern.
Swipe sideways to compare every column.
| Real need | A mobile website may be enough | An app may earn its place |
|---|---|---|
| Finding the business | Services, prices, directions, search, and contact | Usually no extra value from installation |
| Occasional action | A quote, booking, donation, application, or purchase | Useful only if the wider journey repeats |
| Frequent account use | Possible through a secure web account | Faster return, saved state, and device sign in may help |
| Work without reliable internet | A basic offline page or limited cached content | Queued forms, saved jobs, and later synchronisation may justify an app |
| Camera, location, scanning, or signatures | Web support may cover a simple use case | A central field workflow may need deeper and more dependable integration |
| Time sensitive updates | Email, text message, or account page | Relevant notifications may help known repeat users |
Repeated use can make installation worthwhile
An app has a clearer role when a known customer returns weekly or daily. A fitness member may book classes, show a membership code, receive a schedule change, and track attendance. A delivery customer may follow active orders and speak to support. A care worker may review assigned visits and record required steps.
Frequency alone is not enough. The app must shorten or improve a valuable action. If customers open it only to view information that the website already presents well, the installation has not created much value.
- Saved preferences remove repeated entry
- A personal account stays central to the service
- Information changes during the day
- Users complete a short core action regularly
- The business already has a direct relationship with likely users
Notifications are not the business case
A notification is useful when the person needs to know about something they already care about, such as a changed appointment, completed order, new secure message, assigned job, or required action. Apple and Android guidance both expect notifications to relate to the app's content and remain useful to the person receiving them.
Marketing messages alone rarely justify an app. Email, text messages, wallet passes, or a web account may reach the same audience with less effort. People can refuse notification permission, silence a category, or remove the app.
Before launch, define each notification, why it cannot wait, who receives it, where preferences live, and what happens when permission is refused. Never depend on a push notification as the only record of an urgent or contractual message.
An app is a continuing product, not a finished file
Store submission is one release, not the end. The business needs developer accounts, current store information, privacy disclosures, customer support, monitoring, backend operation, security updates, device testing, and changes for new operating system versions. Apple states that apps should remain functional and current, while Android publishes ongoing quality guidance for supported devices and behaviours.
Name a product owner before development. That person should understand feedback, choose priorities, coordinate releases, and decide when the app should be improved or retired. Also name the technical owner for certificates, store access, dependencies, incidents, and recovery.
- Who answers app users and reviews store feedback?
- Who owns Apple, Google, cloud, analytics, and notification accounts?
- How will account deletion, data export, and lost devices be handled?
- Which phones and operating system versions will be tested?
- What budget and release rhythm continue after the first version?
Prove one useful journey before building the full idea
Describe one person, one repeated problem, and one result. Observe the current work, test a mobile website or clickable prototype where appropriate, and invite a small group of real users. The questions they ask will expose missing steps more quickly than a long feature list.
- How often does this person face the problem?
- Why is a browser journey not enough?
- Which device or offline behaviour changes the outcome?
- How will the first users discover and install the app?
- What evidence will show that the core action is easier?
- Can the business support the app for several years?
Ways to Build or Improve It
Website Development
Business websites and landing pages planned around clear offers, useful journeys, enquiries, and dependable ownership.
Mobile App Development
Android and iOS apps for customer actions, booking, tracking, staff workflows, and app supported systems.
Choose the smallest product that solves the real problem
Build an app when a repeated customer or staff journey becomes clearly better through dependable offline work, device integration, saved personal state, or timely service updates. Use a mobile website when people need broad, occasional access without an installation decision.
Choosing not to build an app can be a strong product decision. It keeps time and budget available for the website, workflow, or service improvement customers will actually use.
Sources and Further Reading
- Apple App Review Guidelines. Current requirements for app completeness, minimum functionality, notifications, privacy, and continuing quality.
- Android Core App Quality Guidelines. Current Android guidance for stability, permissions, notifications, usability, and supported device behaviour.
- web.dev Learn Progressive Web Apps. Google's web platform guidance for installable web experiences, offline access, caching, and notifications.
- MDN: What is a progressive web app?. A current explanation of web, progressive web, and platform specific app capabilities and tradeoffs.
Editorial note: This guide deliberately includes reasons not to build an app. Platform capabilities and store requirements change, so every required feature should be checked against current official documentation and tested on the devices people will use.