Do You Actually Need a Mobile App? A Decision Framework

Most businesses that ask for a mobile app are describing a problem a mobile website would solve. Some genuinely need the app. Telling the two apart before you commit is worth more than any feature list.

The three tests

An app earns its cost if you can answer yes to at least one of these — honestly.

Frequency. Will a typical user open this more than once a week? Apps live on repetition. A service people use twice a year does not survive on a home screen; it gets deleted during the next storage cleanup.

Device capability. Do you need something the browser genuinely cannot do well — reliable background location, offline-first operation, deep hardware access, or push notifications you can depend on? Note that mobile web has closed much of this gap; the honest version of this test is narrower than it was five years ago.

Identity. Is the app the product itself, rather than a window onto it? A delivery service or a banking client is the app. A brochure is not.

If all three are no, you do not need an app. You need a fast, well-built mobile site — and you will get better results for less money.

The cost nobody quotes

Building the app is the smaller half. What follows is permanent:

• Two operating systems ship major releases annually and periodically deprecate things you depend on.
• Store review is a gate between you and your own users. Urgent fixes are not urgent if review takes days.
• Certificates, provisioning and store accounts expire, and always at an inconvenient moment.
• Every user runs a version of your choosing only if you force upgrades, which users resist.

A reasonable planning assumption is that ongoing maintenance costs a meaningful fraction of the original build every year, forever, just to stand still. If that number is not in the business case, the business case is wrong.

Where the middle ground actually is

Before committing to native, two options deserve a serious look.

A progressive web app installs to the home screen, works offline to a degree, and can send notifications on both major platforms. It ships without store review. For a large share of business use cases this is the right answer, and it is dismissed too quickly.

Cross-platform frameworks give you one codebase for both platforms. The trade-off is real but usually acceptable outside graphics-heavy or deeply hardware-integrated products.

Going native from the start is right when performance is the product, or when you need platform capabilities the moment they ship.

The Saudi context

Mobile is not a secondary channel here — more than 40% of e-commerce orders in the Kingdom start on a mobile device. But that argues for mobile quality, not necessarily for an app. A slow, poorly localised mobile site loses those orders whether or not an app exists.

If you serve Arabic-speaking users, the app raises the localisation bar rather than lowering it: right-to-left layout, Arabic numerals, Hijri dates where relevant, and text that was written in Arabic rather than translated into it.

A cheaper way to find out

Before funding a full build, ship the mobile web version of the core journey and measure. If people use it repeatedly and hit its limits, you have evidence for an app and you know exactly which limits to design around. If they do not use it, you have saved yourself a permanent maintenance obligation.

That sequence costs a fraction of a native build and answers the question with data rather than conviction.

---

Not sure whether an app is the right call for your business? Start a project and we will work through it with you.