The mobile app you probably should not build

A studio that sells mobile development should probably not talk you out of a mobile app. Consider this a conflict of interest disclosure: we make money when you build one, and we still say wait more often than we say yes.

The reason is arithmetic, not ideology.

A native app is not one product. It is two more codebases (or one more, with React Native and careful choices), two release pipelines, two review processes with multi-day approval delays, and a long tail of OS updates, device quirks, and store policy changes. Every feature you ship afterward costs two to three times what it costs on the web. That multiplier never goes away. It compounds.

Meanwhile, the modern web quietly took over most of what people think they need an app for. Installable icons, offline caching, push notifications on every platform that matters, camera access, payments. A well-built web app opens instantly from a link, needs no store approval to fix a bug on a Saturday, and works on the laptop where your users actually do their serious work.

So the question is never whether an app would be nice. It is whether your product depends on the few things only native software does well:

The product lives in the background: continuous location, sensors, health data, offline-first workflows in places with no signal. The product’s core interaction is deeply gestural or graphics-heavy, where 120 frames per second is the feature. Or your users demonstrably live on their home screen and retention data, not intuition, says the icon matters.

If one of those is genuinely true, build the app, build it properly, and budget for its whole life rather than its launch. That is work we love.

If none of them are true yet, version one should almost always be the web app, instrumented well enough to tell you when that stops being the right answer. The strongest mobile apps we have shipped were second products, built after the web version proved what users actually do, which is rarely what the pitch deck assumed.

Saying wait costs us a project sometimes. It is still the correct advice, and we would rather be the studio you trust in year three than the one that billed you for two codebases in year one.