A native mobile app costs roughly two to four times what a comparable web product costs to build and maintain. It pays back less often than founders expect. Most early-stage teams that ship a native app would have been better served shipping a great mobile web experience and reinvesting the savings.
That is an unfashionable view. Here is the framework we use with clients.
The four reasons to build a native app
There are four legitimate reasons to invest in native:
You need a capability the web cannot deliver. Background services, deep OS integration, low-level Bluetooth, AR. If your product depends on one of these, native is the answer.
Your retention model depends on push notifications. Web push is real but limited. If your business case lives or dies on re-engagement, native gives you better tools.
Your usage is so frequent that the home-screen icon is worth a measurable conversion uplift. This is real for a small set of products (banking, messaging, fitness tracking) and imaginary for most.
You are distributing through the app stores for trust or discovery reasons. B2C health, finance, and education products often fall here. B2B SaaS very rarely does.
If none of these apply, do not build a native app. Build a mobile-first responsive web product. Add a PWA wrapper if you want an installable experience.
The hybrid trap
React Native, Flutter, and Capacitor are good technologies that have been mis-sold to teams that wanted to avoid the cost of two codebases. They are not magic. A hybrid app is still a native app — it needs app-store releases, native build tooling, platform-specific QA, and a release manager. The savings versus two native codebases are real but smaller than the marketing suggests.
If you have decided you need a native app, hybrid is a sensible default. Just budget realistically.
The pragmatic path for most B2B SaaS
Ship a great responsive web app. Audit the mobile experience as carefully as the desktop one. Add a small wrapper for installability if the product warrants it. Revisit the native question when you have a concrete reason to build one — not before.
The teams that follow this path consistently outpace the teams that spent a year building an app nobody downloaded.