When a mobile app is the wrong answer

We build native and cross-platform mobile apps regularly, and we still tell a meaningful share of prospective clients that a responsive web app is the better answer for their specific situation. Saying yes to every app request would be good for short-term revenue and bad for a client's actual outcome.

A native app has to be discovered, downloaded, and installed before a user ever experiences it, a meaningfully higher-friction path than clicking a link to a web app. For a product without an existing engaged audience actively searching app stores for a solution like it, that distribution friction alone can sink usage regardless of product quality.

A web app deploys instantly; a native app update goes through platform review and depends on users actually updating, which a meaningful percentage never do promptly. For a product in an early, fast-iterating stage where the team is shipping meaningful changes weekly, that lag is a real cost to development velocity, not a minor inconvenience.

If the product genuinely needs deep native functionality, background location tracking, offline-first field use, push notifications as a core mechanic, camera or sensor integration beyond what a web app can access, native is the right call and we say so clearly. If none of those apply, we ask why "app" is the assumed format rather than the actual requirement.

Modern web capabilities, installable progressive web apps, push notifications in supporting browsers, offline caching through service workers, close much of the experiential gap that used to clearly favor native. For a large share of MVP-stage products specifically, this gets a founder something that feels considered and fast without the app store distribution tax.

A founder came to us wanting a native app for a scheduling tool aimed at small service businesses. We built a progressive web app instead, which the target users could start using immediately by clicking a link with no app store friction. Six months and real usage data later, when a genuine case for native features emerged, that was the right time to build it, not before.

We ask what specific native capability is required, what the realistic distribution plan is, and how fast the product needs to iterate in its first six months. Those three answers usually make the right format obvious, and we'd rather have that conversation upfront than build the wrong thing well.

Founders sometimes push for native specifically because they believe an app store presence signals legitimacy to investors or early customers, and that instinct isn't baseless, but it's worth weighing against what an app store listing with a handful of downloads and no reviews actually signals compared to a polished, fast, well-used web app with real numbers behind it. We've watched a credible web app with genuine usage data outperform a native app nobody's downloaded yet in exactly the credibility test it was meant to pass.

This isn't an argument against native, it's an argument for being honest about what problem native is actually solving in a specific case. If the real goal is credibility rather than a specific native capability, a well-built web app with strong performance and real users usually earns that credibility faster and cheaper than a native app sitting in an app store with minimal traction.

For cases where native capability is genuinely required but budget or timeline can't support two fully separate native codebases, React Native or an equivalent cross-platform framework lets a single codebase ship to both iOS and Android with access to most native APIs. We recommend this middle path more often than either pure native or pure web when the requirement genuinely calls for device-level access but the team doesn't have budget for two parallel native builds.

A web app that was the right call at MVP stage doesn't have to stay the right call forever, and we build the initial architecture with a plausible native migration path in mind rather than one that would need to be rebuilt entirely from scratch if native ever becomes genuinely necessary later.

A native app quoted as a single build often understates the real ongoing cost, since two platforms typically mean two codebases to maintain, two sets of platform-specific bugs to chase, and two separate review and release processes to manage indefinitely, not just once at launch. We lay out this ongoing cost explicitly during scoping, not just the initial build price, since it's the number that actually determines whether native is sustainable for a specific team's budget over time.

This ongoing cost is exactly what a web app or a single cross-platform codebase avoids, and for a founder weighing a tight runway against a multi-year maintenance commitment, that difference is often more decisive than the initial build cost comparison alone. We'd rather have this fuller conversation upfront than let a founder discover the real maintenance burden only after committing to two native codebases.

If a founder walks away from this conversation still convinced native is right for their specific situation, we build it, and we build it well. The goal was never to talk anyone out of native as a matter of principle, it was to make sure the decision reflects the product's actual requirements rather than a default assumption nobody had examined closely. Founders who go through this exercise, even the ones who land back on native, tell us afterward that they're glad the format was actually questioned rather than assumed, since it's rarely a conversation anyone else in the process thought to have with them.

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.

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.