"We need an app" is one of the most common sentences we hear from business owners, and one of the least examined. It usually means one of three things: a competitor has one, a customer asked for one, or the website is not doing its job and an app feels like a fresh start.
None of those is a reason to build software. Some of them are reasons to fix the website. One of them might be a reason to build an app. This article is about working out which.
An app is not a marketing channel. It is a product. It has to earn a place on someone's phone every single day.
Start with the job, not the format
Before asking "should we build an app", ask a more useful question: what do we want people to be able to do, that they cannot do well today?
Write the answer down as a list of tasks. Book an appointment. Reorder last month's supplies. Check the status of a repair. See their account balance. Get notified when a table is free. Upload a document. Pay an invoice.
Now, for each task, ask three things:
- How often does one person do this? Daily and weekly tasks suit an app. Monthly or yearly tasks do not; people will not keep an app for something they do twice a year.
- Does it need something only a phone can do? Camera, location, push notifications, offline access, biometrics, payments in a tap. If yes, an app has a real advantage. If no, the web does the job.
- Who is doing it: customers, or your own team? Internal tools have very different economics. Your staff will install what you ask them to. Customers will not.
If most of your tasks are infrequent, do not need phone hardware, and are done by customers, you do not need an app. You need a better website, and possibly a web application behind it. If several tasks are frequent, phone-native, and done by the same people repeatedly, keep reading.
The alternatives that usually win
Most of the outcomes people want from an app can be reached faster and cheaper another way. Consider these first, in order.
A website that actually works on a phone
Many "we need an app" conversations end when the owner tries to book their own service from a phone and cannot. A fast, clear, mobile-first website with the key tasks on the front page solves the most common complaint at a fraction of the cost, and improves your search visibility at the same time. An app does nothing for search.
A web application
A client portal, a booking system, an ordering tool, or a dashboard does not need to live in an app store. Built as a web application, it runs in any browser, needs no installation, updates instantly for everyone, and is reachable from a link in an email or a search result. For most businesses this is the right first product.
An installable web app
Modern browsers let a well-built web application be added to the home screen, work offline, and send notifications on most devices. This gives you much of the "app feel" without an app store, a second codebase, or review delays. It is often the best compromise for businesses that want presence on the phone without the cost of native.
Someone else's platform
If your customers already live in a messaging app, a marketplace, or a booking platform, meeting them there may beat asking them to install something new. The trade-off is that you do not own the relationship or the data. Use these to reach people; do not make them your only presence.
When an app is the right answer
An app earns its place when the alternatives genuinely fall short. Common cases:
- The product is the app. If what you sell is software people use on their phones, this article is not for you. Build it, carefully.
- Frequent, repeated use by the same people. Members, patients on a care plan, regular customers, field staff. Weekly or better.
- The phone's hardware matters. Scanning, photographing, navigating, working offline in the field, tapping to pay.
- Notifications are central to the value. Not marketing pushes; timely, useful alerts the person actually wants.
- Internal operations. A tool for your own team, where you control installation and can design for one job done fast.
Notice what is missing from that list: "our competitor has one" and "it would look more professional". Those are feelings, not reasons. An app with no users looks less professional than no app at all, and app store listings with three downloads and one bad review are public.
What an app really costs
The build is the smaller part. Budget for the whole life of the product:
- Design and build. The number everyone asks for. It depends entirely on scope, and a good first version is far smaller than most people imagine.
- Two platforms. iOS and Android are different worlds. Cross-platform tools reduce, but do not remove, the extra work.
- The back end. Apps talk to servers. Accounts, data, payments, and notifications all need infrastructure that has to be hosted, secured, backed up, and monitored.
- App store accounts, reviews, and rules. Annual fees, review delays, policy changes, and the occasional rejection.
- Operating system updates. Every year both platforms change. An app that is not maintained will eventually stop working or be removed.
- Getting people to install it. This is the cost nobody budgets. A website is found by search. An app must be marketed, explained, and re-explained.
- Support. Someone will forget a password on a Sunday.
A useful rule: if you cannot commit to maintaining the app for at least three years, do not start. A dead app on a customer's phone is worse for trust than a page that does not exist.
If you do build: start smaller than you want to
The most common failure is not building the wrong app. It is building too much of the right one. A first version should do one job, for one group of people, very well. Everything else goes on a list for version two, and most of that list never gets built because real users will tell you what they actually need.
- Pick the one task from your list with the highest frequency and the clearest phone advantage. Build that.
- Build the back end to last. The app is the visible part; the accounts, data, and integrations underneath will outlive several redesigns. Get those right.
- Own everything. Source code, developer accounts, domains, and data should be in your name from day one, whoever builds it. This is not negotiable.
- Design for accessibility from the start. It is cheap at the beginning and expensive later, and it is increasingly a legal requirement.
- Measure from the first day. Installs are vanity. Repeat use is the number that tells you whether the app deserves to exist.
- Keep the website strong. The app does not replace it. Search, AI answer engines, and first-time visitors will still arrive through the web.
A short decision guide
If you want the one-paragraph version:
Fix the mobile website first; it helps everyone, including search. If customers need to log in and do things, build a web application, and make it installable if phone presence matters. Build a native app only when the same people will use it weekly, the phone's hardware or notifications are central to the value, and you can commit to running it for years. Start with one task. Own the code. Measure repeat use, not downloads.
If you are unsure which of these you are, that is a normal place to be. It is also a much cheaper question to answer in a conversation than in a build.