Most businesses do not need an app

Does my business need an app? The honest answer

For most businesses, no. You need an app only when customers have a repeated reason to open it, or when the job needs something a browser handles badly: push notifications, offline access, or direct use of the camera, GPS, or a digital wallet. If your customers deal with you a handful of times a year, a fast mobile website will beat an app on reach, cost, and upkeep.

Usage data explains the caution. The average smartphone carries more than 80 installed apps, yet only about 9 to 10 are opened on a given day and roughly 30 to 34 in a month, which leaves over 62% of installed apps untouched month to month.⁴ Installs keep growing, with 142.2 billion apps and games downloaded globally in 2025, up 3.1% year on year.⁷ Growth in downloads is not growth in attention.

Attention is the constraint. Smartphone owners spend roughly 3.6 to 4.6 hours a day inside apps, and that time concentrates in social and messaging rather than in apps belonging to individual businesses.⁸ Even the fastest-growing category behaves this way. Time spent in generative AI apps rose 426% year on year, a narrow spike in one category rather than broad appetite for more apps from more brands.⁹

When to build an app: four tests it has to pass

Put the business through four tests before anyone writes a line of code. If none of them returns a clear yes, the app is a want rather than a need.

Frequency

Does a typical customer have a reason to open the app at least weekly? Reordering, booking, tracking, loyalty, and account management pass. An annual renewal or a one-off purchase does not. Weak frequency is what the 90-day churn figure measures: the icon sits on the home screen for a quarter, then goes.

Hardware

Does the job need the camera, GPS, Bluetooth, biometrics, or offline storage in ways the mobile browser struggles with? Field service, in-store scanning, delivery routing, and identity verification pass. A menu, a brochure, or a contact form does not.

Notifications

Do you have something genuinely time-sensitive to send? Push notifications achieve about an 80% open rate against roughly 20% for email.¹ That is a real advantage and a real liability. The channel that makes a delivery alert useful is the same one that burns goodwill when it carries a promotion nobody asked for.

Commercial lift

Will in-app behaviour move money? Eight in ten brands report a higher average order value in the app, with a median lift near 9%.¹ Separately, 70% of consumers say they would rather book or order through an app than a mobile website.¹ Both figures come from brands whose customers already had a reason to install. They describe the ceiling for a suitable business, not a floor for any business.

Does my business need an app, or a better mobile website?

Most of the mobile app vs website for business debate collapses once you separate reach from depth. A website is how people find you. An app is how a subset of them go deeper. The website has to work first, because it is where nearly every app install will come from anyway.

A native mobile app is software built for iOS or Android, distributed through the App Store or Google Play, with full access to device hardware such as the camera, GPS, push, and offline storage. That distribution is the part first-time buyers overestimate. Store discovery does very little for a new small business app, so installs arrive through the channels a good website already serves for free.

What does a business app really cost?

Published 2025 and 2026 cost guides land in a consistent band. A simple first version sits around 15,000 to 30,000 dollars. A mid-scope build runs roughly 80,000 to 120,000 dollars. Complex multi-platform products start near 180,000 dollars and can pass 300,000.³ Broader small business ranges are quoted from about 15,000 to 120,000 dollars and above.¹²

The build is the visible cost. Maintenance is the one that surprises people. Budget 15% to 20% of the build cost every year for operating system updates, bug fixes, and store compliance.¹² That line never ends while the app exists. A 100,000 dollar app is a 15,000 to 20,000 dollar annual commitment before a single new feature is added.

That abandonment rate is what an unfunded maintenance line looks like at scale. The build gets signed off, the second year never gets budgeted, and the product quietly stops keeping pace with the operating systems it runs on.

Is a progressive web app the smarter middle path?

Often, yes. A progressive web app is a website built to behave like an app. It installs to the home screen straight from the browser, caches content for offline use, and can send notifications, all without app store distribution or approval. It captures a large share of the retention benefit at a fraction of native cost, and it ships the moment you deploy it.

A PWA is the right first move when frequency is plausible but unproven. Ship it, watch whether people install it and come back, then let real behaviour decide whether native is worth a six-figure build. Native still wins when you need deep hardware access, background processing, or the in-app purchase mechanics only the stores provide.

The cheapest way to learn whether customers will use your app is to give them something app-shaped that costs a tenth as much.

How do you calculate app ROI before you build?

App ROI is the net financial return from an app measured against its full cost, including build, store fees, and ongoing maintenance, usually assessed over 12 to 24 months. Model it before you commit, using four numbers you already hold.

1. Installable audience. Take your existing repeat customers, not your total traffic. Only people who already come back will install.
2. Realistic install rate. Assume a fraction of that base installs, and that most of the rest never will, however many prompts you run.
3. Users retained after 90 days. Apply the churn reality above. Plan on a minority still active a quarter later unless you have a loyalty, reorder, or booking hook.
4. Value per retained user. Use your own average order value with a modest uplift, not a best-case multiple borrowed from a vendor study.

Multiply those four and set the result against build cost plus two years of maintenance. If the payback period runs past 24 months on optimistic inputs, the answer is no. Running this model honestly is the most useful hour in the whole decision, and it is where any serious product development consulting engagement should start.

When you do not need an app at all

Several patterns almost never justify one.

• Low interaction frequency. Annual services, considered one-off purchases, and long sales cycles.
• No hardware requirement. If the work happens in forms and content, the browser already does it.
• Discovery-led demand. If most customers arrive through search, an app cannot serve them at the moment of intent.
• No maintenance budget. If year two funding is not agreed in writing, do not start.
• An app as a status project. Wanting to be in the store is not a customer need.

In these cases the money goes further on site speed, checkout, booking flow, and content. Those improvements reach every customer, not just the fraction who would have installed.

A decision sequence you can run this week

1. Count how often your top 100 customers interact with you in a year. Under twelve, stop here and improve the website.
2. List the jobs that need hardware or offline access. If the list is empty, take native off the table.
3. Write the notification you would send this week. If you cannot write twelve useful ones for the year, push is not your case.
4. Build the ROI model above with pessimistic inputs and a 24-month window.
5. If the case still holds, scope a PWA or a narrow native first release around a single job, using a structured design thinking process to define that job before anyone estimates it.

The discipline matters more than the verdict. Teams that run this sequence and decide against an app usually redirect the budget into work with a shorter payback. Teams that run it and proceed build something narrower and better used than the app they first described. Either outcome beats an unexamined yes. If you want a second opinion on the model, our product development practice runs this as a fixed assessment, and you can start that conversation here.

Written by the group's editorial team with the practice leads who run these builds. Reviewed before publish. Spotted an error? Tell us and we will fix it.