Every few months a business owner asks us to build them a mobile app, and the first thing we do is try to talk them out of it. Not because apps are a bad idea — we build them — but because roughly half the people who ask for one actually want something else, and the ones who find that out after spending their budget are the ones who end up with an app nobody downloads.
This is the conversation we have with them, written down.
First question: does the job need an app at all?
An app earns its place when at least one of these is true:
- People use it repeatedly. Not once a year to check a price — weekly, ideally daily. Installing something is a real ask, and a user only agrees to it for something they will come back to.
- It needs the device itself. Camera, GPS, offline storage, Bluetooth, push notifications, background location. If your product needs to scan a barcode in a warehouse with no signal, that is an app.
- It has to work offline. A website without a connection is a blank screen. An app can hold data locally and sync later.
- The relationship is ongoing. Accounts, saved history, personalisation, a reason to send a notification that is actually welcome.
If none of those apply, what you probably need is a fast, well-built mobile website. It costs less, needs no store approval, works on every device, gets found in search, and updates the moment you publish. A restaurant does not need an app. A logistics operation whose drivers scan deliveries in areas with patchy signal does.
Native, cross-platform, or web?
Once an app is justified, the next decision is what to build it with. There are three honest options.
Native (Swift for iOS, Kotlin for Android)
Two codebases, two teams' worth of work, the best possible performance and immediate access to every new platform feature. Worth it for graphics-heavy products, anything doing continuous background work, or apps where a dropped frame is a business problem. For most business apps it is paying twice for a difference users will not notice.
Cross-platform (React Native, Flutter)
One codebase, both platforms. This is where most business apps should start. The performance gap against native has narrowed to the point of irrelevance for form-driven, list-driven, content-driven products — which is nearly all of them.
Our own parenting app, DADI, is built this way in React Native with Expo. It tracks a child's growth measurements, developmental milestones, vaccination schedules and photo memories, and shares them across a family. Every one of those features is lists, forms, charts, local storage and notifications. Writing it twice would have doubled the cost and delivered an identical experience.
Progressive web app
A website that can be added to the home screen, works offline and can send notifications on Android. No store, no review process, no install friction, and the same URL structure that search engines already understand. The compromise is weaker device integration and thinner support on iOS. For an internal tool used by staff on known devices, it is very often the right answer and the cheapest one.
What an app actually costs
The build is the part people budget for, and it is not the expensive part over five years.
- Discovery and design. Deciding what version one is, and what it deliberately is not. Skipping this is the single most common reason a build overruns.
- The build itself. Roughly proportional to the number of distinct screens and the number of integrations, not to the size of your company.
- Backend and hosting. An app is a window onto a server. Accounts, data, sync and push all live there.
- Store fees and review. Apple and Google both charge to publish and both review what you submit. Budget calendar time for rejections; they are routine, not a disaster.
- Maintenance — the one people forget. Both platforms ship a major OS release every year, and both periodically raise the minimum SDK you must target to stay listed. An app that gets no attention for two years does not sit still; it stops being downloadable.
Treat maintenance as a standing line item from day one. An app you cannot afford to keep current is a liability with your logo on it.
Scoping version one
The apps that succeed launch narrow. Pick the single thing your user needs most and make it excellent, then let real usage tell you what comes second.
A practical test: write down every feature you want, then ask of each one whether a user would still install the app if it were missing. Everything that survives is version one. Everything else is version two, and some of it will quietly turn out to be version never — which is the cheapest possible outcome for a feature nobody wanted.
Before you commission anything, agree these
- Who owns the code and the accounts. The App Store and Play Console accounts should be registered to your business, not to your developer. This matters enormously the day you change developer.
- Where the data lives, who can export it, and in what format.
- What happens after launch — who ships the OS-compatibility updates, at what cost, and how quickly a critical bug gets fixed.
- How success is measured. Downloads are vanity. Returning users in week four is the number that tells you whether you built the right thing.
The short version
Build a mobile website unless you need repeat usage, device hardware or offline capability. If you do need an app, start cross-platform, launch narrower than feels comfortable, own your own store accounts, and budget for the years after launch rather than just the months before it.
If you are weighing this up, we are happy to tell you honestly which of the three routes fits — including the one where the answer is that you do not need an app at all.
Common questions
How long does it take to build a mobile app?
A focused first version with a handful of screens and one backend integration is typically a few months from discovery to store approval. What stretches a timeline is rarely the coding — it is undecided scope, waiting on content or third-party access, and store review cycles. Agreeing exactly what version one contains before the build starts is the single biggest lever on the schedule.
Is React Native good enough, or do we need a native app?
For form-driven, list-driven and content-driven business apps, React Native is good enough that users cannot tell the difference, and it halves the cost of supporting both platforms. Choose native when you need sustained high-frame-rate graphics, heavy background processing, or a brand-new platform capability the day it ships.
Do we need an app, or would a mobile website do?
Choose a website unless you need at least one of three things: genuinely repeat usage, device hardware such as camera, GPS or Bluetooth, or the ability to work offline. A website is cheaper, is found in search, needs no store approval, and updates the moment you publish it.
What does it cost to keep an app running after launch?
Plan for annual compatibility work regardless of whether you add features. Apple and Google each ship a major OS release every year and periodically raise the minimum SDK an app must target to remain listed. Add backend hosting, developer account fees, and a budget for fixing what real users find in the first months.
Who should own the App Store and Play Console accounts?
Your business, always — registered to your company, with your billing details and your access. Apps published under a development agency's account become very difficult to move if you ever change supplier, and the listing, reviews and install base all sit with the account holder.
