Half the time, you don't need a mobile app

About half the mobile briefs we see don't need a mobile app. They need a mobile-friendly web flow with one notification permission, sometimes a saved-to-home-screen prompt, and the budget that would have gone to App Store review goes back into the actual product. We tell people this before they sign, because by week eight it's a much more expensive conversation.

The honest test is one question: does this thing need the camera, geolocation, audio, or background work? If yes, native or React Native earns its place. If no, you're paying for an app store presence — not for an app. Store presence is a real thing to pay for in some categories (consumer brands, anything where a 4.7-star rating is part of the trust chain). It is not the same thing as needing the app to be an app.

The shape of the decision matters because the cost of being wrong isn't symmetric. Picking native when web would have done wastes a quarter of the budget and ten weeks of calendar; picking web when native was needed wastes the entire build and you start over in month four. Our default is to start with web and make the brief argue itself into native — not the other way around.

Things that quietly turn out to be web flows: most loyalty programs, most onboarding portals, most "we want our customers to have an app on their phone" briefs from B2B companies whose customers will install one app this year and it won't be the one you were thinking of. The home screen is rented. App stores enforce a quarterly tax. Push notifications, the one thing operators usually want, work fine through the web on iOS since 2023 and have on Android for a decade.

The chart above is the part of the conversation that ends most app debates. Across our mobile projects, the apps that stayed on the home screen at thirty days were the ones where the user opened the app to do a job — scan a code, log a shift, find a venue at a festival. The apps that got buried in folder four were the ones that asked the user to remember they had been installed. The web is the place for things you want people to remember; the home screen is the place for things they already do.

When we do say yes to native: hospitality scanner apps where staff have a phone in hand all shift and the camera workflow has to feel like a tool. Cultural-route or destination apps where offline-first is the whole product. Stock-keeping apps where Bluetooth handhelds talk to printers on the same warehouse network. Sports timing where milliseconds and the radio matter. The pattern is consistent: native is right when the phone is the work surface, not the destination.

The cheaper truth: most briefs that come to a mobile shop come because the founder saw a competitor's app, not because their users asked for one. We've sat through demos where the app was the deliverable and the workflow it served had been a Google Form for two years and worked fine. We tell the founder. About half decide to ship the web flow first, watch whether the demand actually shows up, and come back in six months for the app. The other half find a different studio. We're fine with both.

What changed since we started saying this out loud: the briefs got better. Founders now arrive with the question pre-answered — "this needs to be an app because the staff have hands full of stock and can't open a browser tab" — which is exactly the kind of brief we want to get. The conversation is shorter and the work is cleaner. Studios that say yes to every app brief are training their clients to bring fuzzy ones. We're training ours to bring sharp ones.