"We need an app" is almost never the actual requirement. Nine times out of ten it means "people need to do this on their phone, away from a desk" — and that's a different problem, with more than one answer.
Getting it wrong is expensive in a specific way: you don't find out until after you've paid for it. So before you commission anything, spend an hour on the question of which kind of app you need.
The three options, briefly
- Web app. Runs in the browser, works on any device, you open it with a link. A modern one can be installed to the home screen and keep working offline for basic use
- Cross-platform native. One codebase, real iOS and Android apps in the stores. This is what most business apps are built with today
- Fully native. Separate iOS and Android codebases. Maximum performance and platform access, at roughly double the build and maintenance
When a web app is enough
A web app is the right answer more often than the market suggests, and it's the cheapest thing to change after launch. It fits when most of these are true:
- Your users are on wifi or decent mobile coverage almost all the time
- They log in — so app store discovery is worth nothing to you
- You don't depend on hardware beyond the camera and basic location
- The audience is internal staff, or business customers you already have a relationship with
- You want to ship a fix the same day, without waiting on anyone's review process
For internal tools — a field engineer logging jobs, a warehouse team checking stock, a manager approving orders — a web app is usually the correct engineering answer. Nobody browses the App Store looking for your internal approval tool.
What native actually buys you
Native earns its extra cost when you need things a browser handles badly or not at all:
- Notifications you rely on. Web push exists on both platforms now, but it's less reliable and easier for users to lose. If a missed alert means a missed shift or a missed delivery, go native
- Serious offline work. Hours of use with no signal, syncing when it returns — an inspection in a basement, a rural delivery route
- Hardware. Continuous background location, Bluetooth devices, NFC, or barcode scanning at hundreds of scans an hour
- Consumer distribution. If you need to be found in an app store, or if being absent from it costs you credibility with your customers
The app store tax nobody puts in the quote
Native apps come with a process attached. Apple charges €99 per year for a developer account; Google charges a one-off €25. Every release goes through review — usually a day, occasionally a week when something gets questioned. You'll need store listings, screenshots, a privacy policy and privacy labels that stay accurate.
And you no longer control what version people run. Some users will sit on a build from eight months ago, so your backend has to keep supporting it. None of this is a reason to avoid native, but it belongs in the decision, because it's ongoing work a web app simply doesn't have.
Cost and timeline, side by side
- Web app: €20,000–€60,000, 2–4 months. One codebase, one deployment, changes live in minutes
- Cross-platform native: €40,000–€90,000, 3–6 months. Two stores, one codebase, plus release overhead
- Fully native, both platforms: €80,000–€160,000, 5–9 months. Justified when performance or deep platform integration is the point of the product
Maintenance follows the same pattern: budget 15–20% of the build per year for a web app, and closer to 20–25% for native, because iOS and Android force upgrades on their own schedule whether you have new features or not. There's more on that in the piece on what maintenance actually costs.
The sequence that saves money
If you're genuinely unsure, build the web app first. It's cheaper, it's faster, and it teaches you what people actually do with it. If usage then shows you need push notifications or offline capability, you build the native app knowing exactly which screens matter — and the backend you already paid for is reused as-is.
The reverse order hurts. Starting native and discovering six months in that half your users are on a desktop browser means paying twice for the same functionality. Related reading: when to stop building and ship, and the broader guide to mobile app development if you've already settled on an app.
The question that settles it
Ask what happens to the user at the exact moment the connection drops or the notification doesn't arrive. If the answer is "they refresh in a minute," build a web app. If the answer is "the job doesn't get done and someone calls the office," you need native — and the extra cost is buying reliability, not polish.
Working out which one fits?
I build both, so there's no reason for me to push you toward the more expensive one. Tell me what your users are doing when they open it and I'll tell you which route makes sense, with an estimate for each.