Do we need a mobile app?

Most people meet it from the outside. A competitor has launched an app, the board asks why you do not have one, or an agency has shown you a handsome app design. Then you are left with a concrete task and pressure to pick a format before anyone has looked at where the need arises and who will use the solution.

Our experience is straightforward: many app wishes are web apps in disguise, and some are not software needs at all yet. An installed app is the most expensive route, both to develop and to run, with app stores, versions and testing on devices. The questions here are built on the criteria that recur in international advice on web versus app, held up against our own projects.

A mobile web app opens from a link and today handles login, personal data, camera, GPS, payment and upload. A PWA (progressive web app) is a web app that on top of that can be installed on the home screen with an icon of its own, show messages through web push and work partly offline, without going through the app stores. It is updated centrally like a website, and it is often the right first step when the need for mobile use is there but the technical app requirement is not. An installed native app is downloaded from the app stores and is strongest when the solution has to get close to the phone: Bluetooth, NFC, connected equipment, constant location, heavy offline workflows or running in the background.

That is why four rules apply in this tool: push alone never gives you an app, camera and GPS alone never give you an app, login and personalisation alone never give you an app, and branding alone never gives you an app. If the app is to be built, the technology is chosen afterwards, to fit the need.

Yes, in most cases. Modern browsers give access to the camera, photos, location, payment and biometric login while the solution is open. What the web still does not carry reliably across iPhone and Android is the deep integration: Bluetooth, NFC, connected equipment, constant location and work in the background. That is where the installed app earns its place.

An installed app is more expensive all the way through: development for two platforms, launch and approval in the app stores, versions, testing on devices and ongoing maintenance. A web app is updated centrally and reaches users through a link. That is why the tool asks for a business case before it points to an app, and puts an estimate on the complexity of the delivery. Real numbers belong in a discovery call, where we run the sums on your task rather than guessing from a price list that does not fit you.

That is a technology choice, and it is only made once the need is clear. Flutter can cover both iPhone and Android from one codebase and is often the right answer for SME solutions; we choose native, meaning an app built separately for each platform, when the outer limits of the platform have to come into play. This tool answers the more important question that comes before it: whether an app should be built at all.

You can, but that does not make the app used. An app forced on people, one that does not replace or improve a concrete, recurring workflow, ends up unused on the phone. The proof is the same as for customers: frequent use of the task today, or a test showing that the solution genuinely helps in the work.