A mobile app is one of the easiest ways for a company to spend a serious budget on something nobody opens twice. For the right business, it is also one of the most valuable products it will ever own.
The difference is rarely technical. It comes down to one question, and a few practical trade-offs that are worth understanding before anyone writes a line of code.
The test: is there a repeated moment of use?
Describe, concretely, the moment someone opens your app. Not the type of user, the moment: where are they, what just happened, and what do they want to do in the next thirty seconds?
If that moment exists and repeats, daily, weekly, on every shift or every delivery, an app is probably worth building. If the honest answer is "when they want to find out about us", you need a fast mobile website, and the app budget is better spent elsewhere.
When a mobile website is the better choice
- People find you through search, ads or links, and usually visit once or occasionally.
- The main goals are information, enquiries, bookings or one-off purchases.
- You want every change live immediately, without app store reviews.
- The budget has to cover content, SEO and marketing as well as development.
When an app earns its place
- A habit: booking, ordering again, tracking, logging, messaging, anything a customer does routinely.
- The device matters: camera, location, offline work, background notifications or biometric login.
- Internal teams who do not work at a desk: field engineers, drivers, warehouse and store staff, inspectors. The moment of use is obvious and repeats all day.
- Being on the home screen is itself valuable, because the product competes for attention every day.
The trade-offs, side by side
- Discovery: websites are found through search; apps are found in the stores, and usually only by people who already know you.
- Friction: a website opens from a link; an app has to be installed first, which loses people along the way.
- Updates: website changes are live immediately; app updates go through store review and users updating.
- Capabilities: apps have deeper access to the device and work better offline; websites can do more than most people assume.
- Running costs: an app adds store accounts, release management and support for older OS versions.
What about progressive web apps?
A progressive web app is a website that can be installed on the home screen, work partly offline and, on current iOS and Android, send notifications once installed. For many businesses it is the sensible middle ground: one product, no store review, a shortcut on the home screen.
Its limits show when the product needs deep device access, a presence in the app stores, or the most polished native feel.
Native or cross-platform is the last question, not the first
It is the question everyone opens with, and it barely matters until the others are settled. Cross-platform frameworks such as React Native fit well when the product is mostly shared logic and delivery speed matters. Native development wins when the experience depends on platform capabilities: heavy graphics, deep hardware access, or a feel users will notice.
Decide it from the requirements, openly, and write down why. That note will be worth a lot a year later.
What kills apps that should have worked
- Copying the website: the same content, a slower update cycle and an install barrier in front of it.
- Adding the business model late: subscriptions, trials and payments shape the product and cannot simply be bolted on.
- Treating notifications as a marketing channel: every message that is not useful is a reason to uninstall.
- No measurement: without analytics on the key journeys, nobody can say what to improve.
What an app costs beyond development
The build is the visible part of the budget. An app also comes with running costs that a website does not have:
- Developer accounts: Apple charges an annual fee for its developer program, Google a one-time registration fee.
- The backend: the server, database and APIs the app talks to, and the hosting they run on.
- Yearly platform updates: new iOS and Android versions regularly require changes and a new release.
- Release management: testing on real devices, store review, and supporting users who have not updated.
- Support and analytics, so problems are found before they show up in the store reviews.
Questions to answer before commissioning an app
- What is the repeated moment of use, and how often does it happen?
- What will the app do that the website cannot?
- How will people find and install it?
- Which numbers will tell you, three months after launch, whether it works?
- Who owns the store accounts, and who handles releases after launch?
Frequently asked questions
Can we start with a website and add an app later?
Yes, and it is often the right order. A good mobile website shows which journeys people repeat, and that data makes a much stronger case for an app than a guess.
Do we need both iOS and Android?
Usually yes for a public app, since both are widely used. For an internal app, the devices your company provides decide it. Cross-platform development keeps the cost of supporting both reasonable.
Who should own the app store accounts?
Your company. The app should be published under your organisation, so the listing, reviews and release history stay yours whoever builds it.
