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.