Most businesses that want an app want it for reasons that a better mobile website would satisfy. A few have a genuine case, and the difference is visible in behaviour that is already recorded.
This guide sets out the four conditions that make an app worth the cost, how to check each one against your own traffic, and what to do first if the answer turns out to be no.
Key takeaways
- Frequency decides it: Weekly use gives an app something to attach to; once a year means the browser was the right answer.
- Read your own traffic first: Phone sessions, the task they start and the step they abandon are already in your analytics.
- Improve the mobile page first: It costs a fraction, reaches everyone immediately, and sets the bar the app would have to clear.
- Offline is the one browsers cannot do: If that need is real it justifies the app; if it is theoretical it will not.
Look for the business signal behind the technology
The signal is in your own traffic rather than in a survey. Look at how many sessions already come from a phone, which task those visitors start, and where they stop. People describing the app they would like is a different thing from people struggling with the site you have.
Some interactions do not belong on a phone at all. A long form, a document comparison, a task done once a year with a reference number typed from a letter: these work better on a desk, and an app that forces them onto a small screen is a worse product than a good web page.
Follow one customer task from the moment they decide to do it to the moment it is finished. Note where they are standing, what else is happening, and whether they have both hands free. That context is what decides between a responsive site and an installed app.
Use four lenses to understand the opportunity
Repeat Use
Count how often the same customer comes back. Weekly is a habit and an app has something to attach to, monthly is marginal, and once a year means the browser is the right place for whatever you were planning to build.
Time Sensitivity
Identify what the customer needs to know within minutes and what currently reaches them hours late. A notification that saves someone a phone call is the clearest justification an app has, and it is worth almost nothing if the underlying information is itself delayed.
Device Context
Describe the part of the task that happens away from a desk, with one hand, or while something else is going on. If the whole interaction happens on a laptop in an office, you are building a website that needs installing.
Offline Need
Check whether the customer is ever somewhere the task matters and the signal does not arrive. Genuine offline need is the one requirement a browser cannot meet, and it is also the most expensive thing on this list to build properly.
Assess the current state without buying software first
You can answer most of this from analytics you already pay for. Phone sessions as a share of the total, completion by device, and the drop-off step give you the baseline. Avoid commissioning research before reading what the existing data says, because it usually says something inconvenient about the mobile web experience first.
Decide what useful measurement looks like
Decide in advance what would make an app worth keeping: repeat visits per customer, completion of a specific task, or a reduction in calls about something the app shows. Downloads measure your launch campaign and nothing else.
Set the comparison against the improved mobile web page rather than against today. If a cheaper change gets most of the way there, the app has to justify the remainder, and that is a much harder and more honest test.
When software is likely to help
An app earns its place when the customer comes back often, needs something within minutes, uses it away from a desk, or has to work without a signal. Those four conditions are the whole argument, and a product that meets none of them is a website that requires installing.
If the interaction happens two or three times a year, the install is a barrier rather than a convenience. Push notifications, home screen presence and offline storage are only worth their cost when somebody opens the thing regularly enough to notice them.
For the comparison between an app and a better web experience in full, see Does Your Business Need a Mobile App or a Better Web App?.
Start with a bounded improvement
Improve the single most-started mobile task on the web first and measure completion before and after. It costs a fraction of an app, it reaches everybody immediately, and the number it produces is the bar the app would have to clear to be worth building.
Separate a structural constraint from a temporary problem
Check whether the pattern holds outside your busiest period. Repeat use in December is not repeat use, and a time-sensitive task that only matters during one campaign is a seasonal problem rather than a product one. Look at a quiet month before deciding anything.
Lay the cases out in a grid: routine and urgent down one side, at a desk and away from one along the other. See how repeat use, time sensitivity, device context and offline need behave in each square. Usually one square is the real case and the rest is decoration.
If the need is structural, write the claim so it can fail: this group of customers will complete this task twice a month on a phone. Then watch whether they do. An app justified by a hope rather than a claim gets judged on downloads because nothing else was agreed.
Risks to make visible
| Lens | Common risk | Early response |
|---|---|---|
| Repeat Use | Downloads stand in for repeat use | Agree which repeat-visit figure decides whether the app continues, before launch. |
| Time Sensitivity | Urgency is assumed rather than measured | Find out how late the information currently reaches the customer today. |
| Device Context | The app duplicates the website | List what it does that the mobile site cannot, and cut anything not on that list. |
| Offline Need | Offline need is asserted, not observed | Ask the people in the field to log every time connectivity actually stopped them. |
A 30-day validation plan: Deciding whether your business needs a mobile app
Days 1 to 5: read what mobile visitors already do. Pull the last three months of traffic and separate phone sessions from desktop ones. Find the task phone users start most often and the point at which they give up. You are looking for repeat use and time sensitivity in behaviour you already have, rather than in a survey where people describe the app they imagine wanting. Separate new visitors from returning ones, because an app only has an audience among the people who already come back without being prompted.
Days 6 to 15: improve the mobile web page first. Take that one task and make it work properly on a small screen, with no app involved. Fix the form, the load time and the thing that needs two hands. Measure completion before and after. An improvement here is cheap, it reaches everyone immediately, and it sets the bar an app would have to clear. Compare the completion figures on the same devices, since a gain measured on a new handset in the office says nothing about the customers you have.
Days 16 to 30: test the case only an app can answer. If the task genuinely needs the device, such as working with no signal or alerting someone within minutes, build a small prototype for that one case and put it in front of ten real customers. Their reaction to that single capability is the decision. A general enthusiasm for having an app is not. Ask the ten customers what they would uninstall it for, as that answer predicts retention better than any enthusiasm about the idea.
A practical worksheet: Deciding whether your business needs a mobile app
The honest test for a mobile app is whether the phone adds something the browser cannot. Score your own customer interaction against these rows, and treat a weak score as useful rather than disappointing.
| Decision area | What to record |
|---|---|
| Repeat Use | How often the same customer comes back, and whether that is weekly, monthly, or once a year |
| Time Sensitivity | What the customer needs to know within minutes, and what currently reaches them hours late |
| Device Context | The part of the task that happens away from a desk, with one hand, or while something else is going on |
| Offline Need | Whether the customer is ever in a place where the task matters and the signal does not arrive |
| Measurement | The share of your traffic already arriving from a phone, and what those visitors fail to complete |
A low score across the four rows is not a reason to give up on mobile. It is a reason to improve the mobile web experience, which costs a fraction of an app and does not require anyone to install anything first.
Related guides
- Where this leads next is covered in Mobile App Admin Panel: Features, Roles, and Workflows.
- If you are weighing a build against a platform, read App Launch Checklist: A Practical Pre- and Post-Launch Plan.
When the mobile work in 6 Signs Your Customer Journey Needs a Mobile App gets a budget behind it, Discuss Your Mobile Product.
Ali Boran Gazel