The most expensive decision in a mobile project is made in the first week, usually by someone who has been handed three options and a set of trade-offs they have no way to evaluate. Choose wrong and you either pay twice for capability you never needed, or hit a wall eighteen months in when the framework cannot do the thing your business now depends on.
I have built on all three. Here is how the decision actually goes.
Start by asking whether you need an app
More than half the businesses who ask me for an app do not need one, and it is worth being blunt about why.
An app has to earn a place on someone’s home screen. That means it has to be opened repeatedly — weekly at least, ideally more. If your customers would use it two or three times a year, they will not install it, and if they do they will delete it when their phone runs low on space. A bakery loyalty app gets used. A bathroom fitter’s app does not, however good it is.
The tell is usually in how the request is phrased. “We want an app so customers can book and see our prices” describes a fast mobile website with a booking flow. It will cost a fifth as much, reach everyone immediately with no install, and can be found on Google — which an app cannot.
Build a web app or mobile site when: usage is occasional, discovery matters more than retention, you need it working next month, or budget is genuinely tight.
Build a real app when: people use it repeatedly, you need push notifications that work reliably, it has to function offline, you need the camera, sensors or background location, or the app is the product.
If you do need an app: native or cross-platform
Cross-platform (Flutter) — the default answer
One codebase, both platforms, one bill. For a business app made of screens, forms, lists, a login and an API, users genuinely cannot tell. Flutter draws its own interface, so the result is consistent on both platforms and fast — and when you want a change, you make it once instead of twice.
The economics decide most projects. Native means writing what is effectively two apps, so you pay roughly twice for development and twice again for every feature you add for the rest of the app’s life. Unless something on the native list below applies, that money is better spent on making the product better.
Flutter also has a practical advantage for small teams: one developer can credibly maintain the whole thing. Two native codebases usually need two specialists, and that is a recruitment problem as much as a cost one.
Native (Swift / Kotlin) — when something forces it
Go native when:
- Performance is the product. Heavy graphics, real-time video or audio processing, AR, games.
- You need deep platform integration. Widgets, complex background processing, Apple Watch or Wear OS, CarPlay, advanced camera control, HealthKit.
- A hardware SDK requires it. Plenty of specialist Bluetooth and industrial devices ship native-only libraries, and wrapping them costs more than writing native.
- Platform-perfect feel genuinely matters to your users — occasionally true in consumer products competing on polish, rarely true in business apps.
- You already have a large native codebase and a team who maintain it.
Note what is not on that list: “we want it to feel professional”, “we might need to scale”, “our investors expect native”. None of those survive contact with the cost.
React Native — a reasonable third option
Worth mentioning honestly. If your team already writes React for the web, React Native lets them ship mobile without learning a new language, and that organisational fit can outweigh technical comparisons. If you have no existing React team, I would choose Flutter.
The three questions that settle it
1. How often will one person open this? Daily or weekly → app. A few times a year → website.
2. Does it need something only the operating system can give you? Reliable push, offline, sensors, background work, hardware → app, and possibly native. Screens and data → cross-platform or web.
3. What happens in year two? Native means every future feature is built twice, forever. If your roadmap is long and your budget is finite, that compounding cost matters more than anything you can see today.
What it costs, roughly
In the UK in 2026 — the wide ranges are real, and the bottom of each is a solo developer with no agency overhead, not a worse job:
- Mobile website / web app: £750–£4,000
- Cross-platform app (Flutter), focused scope: £3,000–£20,000
- Native app, both platforms: £5,500–£40,000+
- Ongoing: budget 15–20% of the build cost per year for OS updates, store policy changes and fixes. This is not optional. Apple and Google change requirements annually and an unmaintained app stops working within about two years.
That last point catches people out more than any other. An app is not a thing you buy once. If you cannot fund the maintenance, build the website.
The decision in one paragraph
Start with the mobile website unless you can name a specific reason it will not work. If you can — repeated use, offline, sensors, reliable push — build cross-platform with Flutter. Go native only when a concrete technical requirement forces it, and be able to name that requirement in one sentence. If you cannot name it, you do not have it.
Weighing this up for your own business? Book a free fifteen-minute call and I’ll tell you which of the three your idea actually needs — including when the answer is “none of them”.