Mobile App or Mobile Web? Our Decision Tree

"Let's have an app" is usually a wish, not a solution. Underneath it there's normally this: getting in front of the customer more often. An app is one way to do that — but it's the most expensive and the slowest to pay back. So our first question is: how many times a month will the user open this thing?

If the answer is "once or twice a month", mobile web wins. Downloading an app is a threshold; nobody crosses it for something they open monthly, and if they do, it doesn't stay on the phone. A well-built mobile web experience — fast to open, usable one-handed, with clean payment and form flows — reaches more people in that scenario and costs far less.

If the answer is "a few times a week", the question becomes: do you actually need the device? Sending notifications, using the camera seriously, working offline, tracking location in the background, pairing with device hardware — those are the places native genuinely wins. If all you want is an icon on the home screen, the web can do that too.

And when we do decide on native, we ship most products from a single codebase: two stores, one team, one release calendar. We choose to write separately for each platform when there's a measurable reason — heavy graphics, device-level performance, or deep platform-specific integration.

The path we recommend most often is a sequence: do the mobile web properly first, collect real usage data, then build the app on top of that data. That way you don't have to guess which three screens the app should be built around; your users will already have told you.

The wrong answer is expensive: maintaining an app nobody downloaded and running a mobile experience that loses users cut the same invoice. That's why we make this decision in the first week — not after we've started writing code.