"We need an app" is one of the most common things we hear at the start of a project. Sometimes that is exactly right. Often, what the business needs is a well-built web app, a mobile app later, or one system behind both.
The choice affects your budget, how fast you can launch and how much work the product needs every year after. Here is how we help clients decide.
When a web app is the better start
- People use it occasionally. Booking a trip, requesting a quote, checking a report. Few people install an app for something they do a few times a year.
- People find you through search. Web pages can be found on Google; app screens cannot. If new customers discover you by searching, the web is where they arrive.
- It is used at a desk. Client portals, dashboards and internal tools are usually used on a laptop, where a web app is the natural fit.
- You need to change things often. A web app updates the moment you release. A mobile app update goes through store review and waits for users to install it.
- You want to test the idea first. One codebase, one release process and no store approval make a web app the fastest way to put something real in front of users.
Modern web apps can also be added to the home screen, work partly offline and, on most devices, send notifications. For many products that covers what people expected from "an app".
When a mobile app earns its place
- People use it every day or every week. A loyalty card, a team's daily checklist, a booking app for regular customers. An icon on the home screen is worth having when people come back often.
- It needs the phone's hardware. Scanning, the camera, location in the background, Bluetooth devices or heavy offline use work best, or only, in a native app.
- Notifications are central. Reminders, status updates and alerts are more reliable and more visible from an installed app.
- Being in the stores matters. For some audiences, an App Store and Google Play listing is part of being taken seriously.
The middle ground: one codebase for iOS and Android
Building two separate native apps doubles much of the work. For most business apps, a cross-platform approach produces iOS and Android apps from one codebase, with a look and feel that matches each platform. We use it in most projects and go fully native only when a feature truly needs it.
What an app costs after launch
The build is only part of the cost. Plan for:
- Store accounts and reviews. Every release passes Apple's and Google's review, and listings, screenshots and privacy details need keeping up to date.
- Yearly operating system updates. New iOS and Android versions arrive every year and apps need testing and, sometimes, changes to keep working well.
- Two platforms to support. Even with one codebase, there are two sets of devices to test and two stores to manage.
- A back end. Accounts, data and notifications usually need a server and an API, which also need hosting and care.
Our usual advice
- Build the core once. Design the data, the business rules and the API first. A web app and a mobile app can then share them instead of duplicating them.
- Launch where your users already are. For most new ideas that is the web: quicker to ship, easier to change, findable on search.
- Add the mobile app when usage proves it. When people come back often, or ask for features that need the phone, the app has a clear job from day one.
Some products do need an app from the start, and then we build one. The point is to decide on purpose, not by default.
Not sure which way to go? See how we build web apps and mobile apps, or tell us about your idea and we will help you choose.