Do You Need a Mobile App, or Would a Website Do?

Sooner or later, someone tells every business it needs an app. Sometimes they're right. Sometimes a good mobile website would do the same job for less money and less upkeep. This post is about telling the two apart, and about what building a real app involves if you decide you need one.

We build mobile apps (Mobile App Development is one of our services), so read this as an explanation from an interested party. We've tried to make it useful even if the answer turns out to be "you don't need one".

What an app gives you that a website can't

A modern website works well on a phone. So the question isn't "do people use phones?" They do. The question is whether you need the things only an installed app does well.

• A place on the home screen. An app icon sits on the phone, one tap away. Customers who use you often, like a gym, a delivery service or a loyalty scheme, will open an app far more easily than they'll type a web address.
• Notifications. An app can tell users something at the right moment: an order is ready, a booking is tomorrow, a payment is due. Websites can do some of this, but app notifications are more reliable and more familiar to users.
• The phone's hardware. The camera, location, Bluetooth, and fingerprint or face sign-in. Apps get fuller and steadier access to these than websites do.
• Working without a signal. An app can keep working offline and catch up later. That matters for field staff, drivers, and anyone who works where the signal is weak.
• Being found in the app stores. For some products, the App Store and Google Play are where customers look first.

If none of these matter to your business, you probably need a good mobile website, not an app.

When a website is the better answer

Be honest about how often people will use it. A phone has limited room and attention. People keep the apps they use often and delete the rest. If customers visit you a few times a year, to check a menu, book once or read your prices, an app asks them to do a lot of work for very little. A fast mobile website asks for nothing.

A website is also easier to keep current. You change it once and everyone sees the change straight away. An app update has to pass the store's review first, and then each user has to install it.

There is a middle path worth knowing about. A web app can be built to install on the home screen and behave a lot like an app, without going through the stores. It won't do everything a real app can, but for many internal tools and simple customer services, it's enough. Our post on websites, web apps and SaaS explains the differences.

iPhone, Android, or both?

Usually the answer is both, because your customers carry both. The good news is that you don't need to build the app twice. With a cross-platform framework, React Native in our case, one codebase produces both the iPhone app and the Android app. You pay for one build, not two, and the two versions stay the same as each other.

There are still cases where fully separate apps make sense, mostly when an app pushes the phone's hardware very hard. For a typical business app with accounts, bookings, orders, payments and notifications, one shared codebase is the sensible choice.

What building an app actually involves

The screens are the part everyone pictures. They are only part of the work. The rest is easy to forget in a quote:

• The backend. Almost every app talks to a server, which stores accounts, orders and data and keeps them in sync across devices. That server and its database are built and run separately from the app itself.
• Accounts and security. Sign-up, sign-in, password resets, and keeping each user's data private.
• Payments. If users pay inside the app, Apple and Google have their own rules about how. Which rules apply depends on what you sell, so check this early.
• Store submission. Apple and Google each review apps before they go live, and each one needs a developer account, screenshots, a description and privacy details. A first submission can be sent back for changes, so plan time for it.
• Updates after launch. Phones get a new operating system version every year, and apps need updating to keep up. An app that is never updated slowly breaks.

That last point is the one owners most often miss. An app isn't finished when it launches. It needs looking after for as long as people use it, so plan for that cost from the start.

Accounts in your name

One practical point saves a lot of pain later. The Apple and Google developer accounts your app is published under should be in your business's name, not your developer's. So should the server, the database and the code. If your developer holds the accounts, they hold your app. If you ever change developers, you want that to be a handover, not a negotiation.

Where to start this week

Answer these four questions honestly:

1. How often will a typical customer use it: every day, every week, or a few times a year?
2. Which of the app-only features above do you actually need?
3. What is the one thing a user must be able to do in the first version?
4. Who will look after it after launch?

If your answers are "a few times a year" and "none of them", build a good mobile website and save the money. If they're "every week" and "notifications and offline", you have a real case for an app, and a clear first version to build.