Mobile web, native, or cross-platform: how to decide
Someone tells us they need an app, and we always slow down before agreeing. Not because they are wrong, but because "we need an app" is a decision about format that only looks like a decision about need. It skips the questions that actually determine the right answer: who uses this, what are they trying to get done, and how often. Mobile web, native, and cross-platform are all real options with real trade-offs, and the wrong choice can cost you a year and a lot of money building the wrong kind of thing well. Here is how we work through it, starting from the mistake most teams make before they even get to the trade-offs.
Start with the user, not the format
The most common and most expensive mistake is starting from "we need an app" instead of from the people who will use it. When you lead with the format, you have quietly decided the hardest question before looking at any facts, and you tend to decide it wrong, because "app" sounds serious and modern while "website" sounds like less.
The better starting point is three plain questions. Who are your users, on what devices, in what situations. What are they actually trying to do with your product. And how often do they do it: many times a day, or once a month. The answers point to a format on their own. A tool people open constantly, that needs the camera and works on a subway with no signal, points toward native. A thing people visit occasionally, find through a link, and use for a few minutes, points toward the web, because making someone install an app to do something once is a step most of them will not take. Get the need clear first and the format stops being a matter of taste. This is the same instinct we insist on at the very start of any product, which we wrote about in knowing what to build: decide what the thing is for before you decide what it is made of.
What each option is actually good and bad at
Once you know the need, the trade-offs get concrete. Each of the three options has real strengths and weaknesses.
Mobile web runs in the phone's browser. Its strengths are reach and speed of change: nothing to install, a single codebase, updates that reach every user the instant you deploy, and sharing that is as easy as sending a link. Those are big advantages for anything where reaching people matters more than getting the best possible performance. Its weaknesses are real too. It has limited access to advanced device features, it struggles with demanding performance needs and smooth complex animation, offline use is harder to make reliable, and it is not listed in the app store where many users go looking for apps.
Native means building specifically for iOS and for Android, with each platform's own tools. It is the best option when the experience has to be excellent: top performance, full access to the camera, sensors, and other device features, smooth animation, dependable offline use, and a real app store presence that carries trust and habit. The cost is that you are building and maintaining two separate apps, and every update waits on app store review, so fixes reach users more slowly and you often support older versions for a while.
Cross-platform, using a framework like React Native or Flutter, sits in the middle. You write mostly one codebase and get real apps on both iOS and Android, with app store presence and access to most native abilities. You give up some of the final polish and some control over rare cases, in exchange for building one app instead of two. For a lot of startups that trade is exactly right, because it gives them an app store product at close to web-level cost.
The answer depends on your team, not just the tech
Here is the factor that gets left out of most of these debates, and it changes the answer more than people expect. The right choice depends heavily on the team you actually have, not only on which option is best in the abstract.
Say two teams face the same product. One is strong in web development and has never released a native app. The other has years of iOS and Android experience. The best technical choice is not the same for both. Push the web team into two hand-built native codebases and they will move slowly, make avoidable mistakes, and spend their energy struggling with unfamiliar tools instead of building the product. That same team on a mobile website or a cross-platform framework will move fast. The native team might reasonably go straight to native, because for them it is not a hard task. Ignoring this leads to a common failure: a team picks the option that scored best on a feature comparison, then spends a year underdelivering because it was the wrong fit for their skills. Honest capacity has to be part of the decision, and we stress this whenever a client asks how to shape a team, which connects to what we wrote in a small senior team outbuilds a big one. The strongest choice is the one your people can actually build and maintain well.
Start small and let real usage decide
Because the trade-offs are genuine and the cost of guessing wrong is high, the safest choice is often to start with the simplest option and let real usage answer the harder questions. In practice that usually means a strong mobile website first.
A mobile website, or a Progressive Web App, which is a mobile site that can be added to the home screen and work partly offline, lets you reach users cheaply, release fast, and learn what people actually do with your product. That real usage answers the questions you were only guessing at before. Do users genuinely need offline mode, or did you assume they would. Are they asking for camera features, or were those a nice idea nobody uses. Is app store presence driving people away, or is a link working fine. If the data shows you truly need deep device access or a store presence, you build native or cross-platform then, with evidence instead of a guess. And if it does not, you just saved yourself the cost of two native apps you did not need. This is the same build-small-and-learn approach we apply to products in general, which we wrote about in how to launch a product with minimal resources. You lower the risk of a big commitment by making a small one first and letting real results guide the next step.
Deciding without regret
Put it together and the decision stops being about which format is most popular. Start from the users and the job they are trying to do, not from "we need an app." Weigh the honest strengths of each option against what those users actually require: reach and instant updates from the web, top performance and device access from native, a practical middle from cross-platform. Include what your team can genuinely build and maintain, because the best option in theory is worthless if your people cannot build and release it well. And when the answer is not obvious, start simple, give users something real, and let their behavior make the decision for you.
Do that and you will still sometimes choose a full native app, and it will be the right choice, made for real reasons instead of habit. More often you will find the honest answer is smaller and cheaper than "we need an app" implied, and your users will be better served for it. The format was never the point. The people using it always were.
One input to this decision has weakened, and it is worth removing from your reasoning explicitly. "Building two native apps costs twice as much" was a real argument for cross-platform or web, and for many teams it was the deciding one.
That cost gap has narrowed. What has not narrowed is the rest: two codebases still mean two review burdens, two release cycles, two sets of platform behaviour to remember, and twice as much code to keep working. Decide on the user experience you need and on the platform capabilities you depend on. The build cost, which used to decide a lot of these arguments, is no longer the deciding factor.
