You have an idea. You can picture it in your head. The picture is on a phone, because that's where you spend most of your day, so when someone asks "is it an app or a website," you say "an app."
And then you spend three weeks fighting with Xcode, an Apple Developer account, TestFlight invites, and a review process that takes a week to tell you the icon is wrong.
The mobile app vs web app decision is the most consequential thing you'll choose before you write a line of code, and almost every indie founder gets it wrong on instinct. This post walks through the real tradeoffs, when each one actually makes sense, and the version most vibe-coders should default to in 2026.
What you're really choosing between
Quick definitions, because the words get muddy.
A web app is software you open in a browser at a URL. No download, no app store, no install. Examples: Notion, Linear, Figma, Draftlytic.
A native mobile app is software you install from the App Store or Google Play. It lives on the home screen with an icon. Examples: Instagram, Strava, Headspace.
A PWA (progressive web app, basically a website that can be "installed" to look like an app) is the in-between. It's a web app under the hood, but iOS and Android let users save it to the home screen and it can sort of pretend to be native. Real but limited.
A hybrid app (React Native, Flutter, Capacitor) is one codebase that ships to both iOS and Android, plus often the web too. The AI tools have gotten good at this lately. Lovable, v0, and Bolt.new still skew web-first, but Cursor and Claude Code can wrangle React Native if you ask them to.
Most indie devs picturing "an app" actually want a web app, or a hybrid that runs everywhere. Pure-native iOS-only or Android-only is much rarer than the instinct suggests, and much harder to ship.
The four things that really decide it
Forget "what do you prefer." Four practical factors do the work.
Distribution. A web app lives at a URL. You buy a domain, you push code, it's live, and you share the link in a tweet. A native app lives in two stores, both with review queues (Apple's runs anywhere from 24 hours to a week, Google's is faster but less predictable), and you can't link directly to a feature; you can only link to "download this app." If your distribution plan involves sharing a URL on Twitter, Reddit, or in a newsletter, web wins by a mile.
Update velocity. When you ship a fix on a web app, it's live in minutes. When you ship a fix on a native app, you submit a new build, wait for review, hope nothing gets flagged, and pray users update their installed version (most don't, for months). For a solo founder shipping ten changes a week based on user feedback, that loop is brutally slow.
Monetisation. Apple takes 30% (15% under $1M annual revenue, but still). Google takes the same on Android. Stripe takes 2.9% + 30c. The maths is not subtle: if you're a paid product with any meaningful revenue, going through the app stores is paying a tax for the privilege of distribution. The exception is if your audience won't buy without the app store's payment infrastructure, but for most indie SaaS that's not the bottleneck.
Capability. There are things a web app genuinely cannot do: continuous background location, deep camera control, certain push notification patterns, full offline operation, accelerometer-driven games. If your product needs those, you need native (or a hybrid with native modules). If it doesn't, the web is fine, and 90% of indie ideas don't actually need native capabilities.
The decision rule that drops out of these four: default to web unless one of the four pushes hard the other way.
Where the AI tools currently sit
The state of AI coding tools is also part of the answer, because the tool support shapes what you can ship in a weekend versus a month.
Web is the strongest path right now. Lovable, v0, Bolt.new, and Cursor in a typical Next.js or Vite project will get you from idea to deployed in hours. The tooling is mature, the patterns are well-trodden, and the AI's training data is heavy on web code.
Hybrid mobile (React Native, Expo) is plausible but choppy. Cursor and Claude Code can handle a Expo project, but you'll spend more time fighting native build issues, simulator setups, and TestFlight than you would on the web equivalent. Useful for "I need an app icon on a home screen," painful for "I'm iterating ten times a day."
Native iOS with Swift or Android with Kotlin is the hardest path with current AI tools. The models can write Swift, but the surrounding ceremony (provisioning profiles, certificate management, Xcode quirks) chews up days that a web project doesn't have.
If your idea works on web, default to web. If your idea needs an app icon for credibility but doesn't truly need native capabilities, ship a polished web app and add a PWA install prompt. If you truly need native, expect the build to take three times longer than the web equivalent, and plan accordingly.
When mobile really is the right answer
There are real cases. Don't read this post as "always web." If any of these describe your idea, native or hybrid is probably the right call:
- The product depends on background activity (fitness tracking, sleep tracking, run logging, navigation). Browsers can't do this reliably.
- Your audience overwhelmingly lives in mobile and won't open a browser. Some consumer segments and most under-25 audiences fall here.
- Push notifications are the core engagement mechanic. Web push exists but is awkward on iOS, and users dismiss browser permission prompts more than mobile ones.
- You need camera or sensor access that browsers don't expose well (AR, document scanning with specific framing, voice activation always-on).
- You're targeting a market where "is this a real product" gets answered with "is it on the App Store."
If two or more of those apply, plan for hybrid from the start. If only one applies and it's borderline, build the web version first and add a mobile wrapper later. That order is much easier than the reverse.
A pragmatic order of operations
Here's how this usually plays out best for an indie dev shipping their first app with AI tools.
Step one: build the web app. Whether you're in Lovable for speed, v0 for design polish, Cursor for control, or Bolt.new for in-browser convenience, ship a real web product that solves the core problem at a URL.
Step two: get to a handful of users. Not a hundred. A handful. Watch them try it. Read the questions they ask. See where they get stuck. This tells you more about whether you actually need mobile than any amount of thinking will.
Step three: if mobile is genuinely necessary (and it sometimes is), start from a spec built for the mobile-app shape and wrap the web app in Capacitor or rebuild key flows in React Native. The web app stays where it is, doing the SEO and link-sharing work. The mobile version handles the cases that need native.
The mistake to avoid is starting with the App Store, because the App Store is the slowest path to a user. Shipping a URL is the fastest path to a user. Speed compounds in early indie work; the App Store can come later.
What to write down before you start
Whichever way you go, capture the decision in your project's spec before you open the AI tool. "Web first, mobile maybe later" sounds obvious, but if it's not written down, your AI tool will quietly default to building things that work great on desktop and break on phone screens, or vice versa. A target platform in the spec keeps Cursor, Lovable, or Bolt from inventing the wrong assumption on prompt four.
This is also where target audience and usage pattern matter: a designer building a portfolio tool and an indie dev building a habit tracker want different platform decisions, and the spec should reflect that. What goes into a project spec covers the rest of the fields that shape the build.
Draftlytic asks the platform question early in the project creation flow on purpose. It's the decision the AI tool would otherwise quietly make for you, often wrong. Answering it up front means the generated spec, the implementation plan, and the prompts you eventually paste into your tool of choice all agree on what shape the app is.
Most vibe-coders should be building web apps in 2026. The audience is reachable, the tools are mature, and the iteration loop is fast. If you genuinely need mobile, the path exists, but go in with eyes open. And whatever you choose, pin it in writing before you start prompting.