When a mobile app is the wrong answer and a better website would do

"We need a mobile app" is one of the most common opening requests we hear, and it's frequently not actually the right first move. A well-built, mobile-optimized website answers the underlying need for a meaningful share of these conversations at a fraction of the cost and with none of the app store approval friction, and it's worth genuinely interrogating the assumption before quoting a native app build.

Push notifications, offline access, camera and Bluetooth integration, and background location tracking are genuine reasons to need a native app, since a website, even a well-built progressive web app, has real limits in these areas, particularly on iOS. If none of these apply to the actual product, the case for a native app weakens considerably, regardless of how the idea was originally pitched.

A website is instantly accessible to anyone with a link. A native app requires a download, an install, and often an account creation before a first-time visitor sees any value at all, a meaningfully higher-friction path that measurably reduces the share of interested people who actually experience the product. For a business still validating demand, that friction is a real cost worth weighing against the benefits of native functionality.

A founder came to us wanting a native app for a local services booking product. We asked about the actual required native capabilities and found none: no offline need, no camera or hardware integration, no meaningful case for push over well-timed email and SMS. We built a fast, mobile-optimized website instead, saving roughly $35,000 in build cost and skipping app store approval delays entirely, and it validated demand successfully within two months.

Field service tools needing offline access and camera integration for documentation, fitness apps needing background tracking, and any product where push notification engagement is core to the actual value proposition (not just a marketing nice-to-have) are genuine native-app cases, and we scope those as apps from the start without pushing back, because the underlying need is real.

Before quoting either option, we ask what specific native capability the product actually needs and whether the target user would genuinely download an app for this versus just visiting a link. Those two questions, answered honestly, settle the decision far more reliably than the founder's initial instinct about what a modern product "should" be.

A progressive web app, installable to a home screen and capable of limited offline caching and push notifications on most Android devices, closes some of the gap between a plain website and a native app without the app store approval process or the higher build cost. iOS support for these capabilities has historically lagged Android's, which is worth checking against a product's actual target platform before assuming a PWA covers the full native-capability gap.

We recommend this path for products with a moderate native-capability need, something beyond a plain website but short of the full list that would justify a true native app, and we're explicit with clients about exactly which specific capabilities a PWA will and won't deliver on each platform before committing to it as the answer.

Beyond the initial build cost, a native app carries an ongoing tax a website doesn't: OS updates on both platforms periodically require code changes just to keep an app functioning correctly, independent of any new feature work, and app store policy changes can force unplanned engineering time with little notice. A website has its own maintenance needs, but they're generally lower-frequency and lower-stakes than keeping a native app current across two constantly evolving platforms.

We walk founders through this ongoing cost explicitly during scoping, since it's easy to budget for the launch and underestimate the years of maintenance that follow, and a founder who understands this upfront makes a more informed decision about which path actually fits their long-term resourcing plan.

Beyond technical capability, we ask a more human question: does this specific target user's phone home screen already look like the kind of person who downloads niche apps for a service like this, or are they someone who solves this kind of problem with a bookmarked link and a Google search each time it comes up. Different user populations have genuinely different app-download habits, and a product built for a population that rarely installs new apps outside the handful they already use daily faces a distribution headwind no amount of good marketing fully overcomes.

This isn't a hypothetical concern. We've seen technically excellent apps struggle purely on distribution, competing for a home screen slot against habits that are hard to disrupt, while a functionally simpler website solving the same problem gets used constantly because it never asked for that commitment in the first place.

We ask founders to be genuinely honest with themselves about their own app-download habits as a rough gut check, and then to be even more skeptical of that instinct, since founders are almost always more comfortable installing new apps than their actual target customer, and mistaking your own habits for your user's is one of the more common blind spots in this specific decision.

Some founders push for a native app partly for a reason that has nothing to do with the actual product need: an app in the App Store feels like a more legitimate, more "real" company than a website, regardless of whether the underlying use case actually benefits from native capability. We take this concern seriously rather than dismissing it, since perception genuinely matters for fundraising and partnership conversations, but a fast, polished, well-designed website signals seriousness just as effectively to most audiences that actually matter for early traction.