Guide
Mobile app or website: what do you really need?
10 August 2026 · 6 min read
“I want an app” is a frequent request, and often a website request in disguise. The distinction is not technical, it is economic: a mobile app published on both stores represents several times the budget of a website, and above all a long-term commitment that many projects have not anticipated.
What an app offers that a website does not
- The icon on the home screen: one-tap access, without typing an address. It is decisive for daily use, pointless for an annual purchase.
- Notifications: the only channel that lets you get back in touch without paying for advertising. It is often the real reason for wanting an app.
- Offline operation and access to the phone’s sensors: camera, location, barcode scanning, contactless payment.
If none of these three points matches your actual use, a well-designed website will do the same job for much less.
What an app requires that a website does not
An app is never “delivered” once and for all. Apple and Google change their systems every year, and their publishing rules too. An app left without updates eventually gets removed from the stores or stops working on recent phones. So maintenance has to be planned from the start, not when the problem arises.
On top of that come the developer accounts to open and renew, the review times for every release, and the fact that an urgent fix cannot go live in ten minutes as it can on a website.
The middle way, often the right one
A modern website can be installed on the home screen and run full screen like an app. It does not have access to everything, but it covers a large part of the needs for a fraction of the cost, without depending on store approval.
We regularly suggest this step to clients convinced they want an app: they validate the real use with their customers, then decide to develop a true app once demand has been proven. It is less spectacular and much less risky.
A native app or a shared codebase?
Developing the same app twice, once for iOS and once for Android, doubles the bill and the maintenance work. Current technologies make it possible to share most of the code between the two systems, with a result indistinguishable for the vast majority of uses. We favour this approach, and reserve separate development for projects that genuinely exploit the specific features of a system.
The questions we ask before pricing
- Will your users open this app every week, or twice a year?
- Is a user account needed, and therefore management of passwords and personal data?
- Must the app communicate with a tool you already use — stock, till, accounting?
- Who will respond to user reviews and requests after launch?
The answers determine the quote far more than the number of screens. A poorly scoped project always costs more than one discussed for an extra hour at the start.