Should I build a web app or a mobile app first?

The question sounds simple. The answer depends on where your customers are, what device features your product needs, and how much of your runway you want to spend before your first user ever touches it.

Start with the wrong platform and you spend 3–6 months building something that most of your customers will never download. Start with the right platform and you have a live, testable product in four weeks with money left to improve it.

Here is the full decision framework, with real numbers, real tradeoffs, and a clear recommendation for the most common founder situations.

A web app lives at a URL. Any device with a browser can open it, laptop, Android phone, iPhone, tablet. There is nothing to download. There is no App Store to navigate. You send someone a link and they are in your product within seconds.

A native mobile app requires the user to open an app store, find your listing, download the app, grant permissions, and then use it. Nielsen Norman Group research shows that every extra step in the onboarding flow cuts completion rates by 20–30%. An app store download adds three to five extra steps before a user sees your product.

For most B2B and SaaS products, users start on a laptop. For consumer products, they start on their phone, but their phone has a browser. The question is not whether your audience uses mobile devices. Nearly everyone does. The question is whether they need to install something native on that device to get the value you are offering.

The distinction matters most at launch. When you are still figuring out whether people want your product at all, the fewer barriers between a curious person and your core feature, the faster you learn. Web removes the most barriers.

The initial build cost is only part of the story. A mobile app that costs $15,000 to build can cost $20,000 more over two years in updates, App Store maintenance, and OS compatibility fixes, costs that a web app does not carry.

Mobile apps require annual maintenance even when you are not adding features. Every time Apple releases a new iOS version or changes its API requirements, your app needs an update to keep working. Web apps running on modern infrastructure update continuously with no manual intervention from your team.

Over two years, a web MVP built by an AI-native team costs roughly $14,000–$24,000 in total. The equivalent iOS + Android build runs $56,000–$80,000, four times more, for the same core functionality.

For a seed-stage startup with $300,000 in the bank, that difference is the difference between 18 months of runway and 6 months of runway.

Apple's App Store review takes 1–3 days for a new submission, but that is the best case. First-time submissions from new developer accounts face additional scrutiny. Rejections, which happen to roughly 40% of initial submissions according to Apple's own review data, restart the clock.

Google Play is faster, typically 2–7 days for a new app. But Android represents about 70% of global devices and roughly 45% of consumer spending in most Western markets, which means iOS is usually still mandatory for consumer products.

The real problem is not the review time. It is that every bug fix after launch goes through the same process. On a web app, a critical bug gets fixed and deployed in under an hour. On a mobile app, a fix gets submitted, waits in queue, gets reviewed, gets approved, and then only reaches users after they manually update, a process that end to end can take 3–7 days.

For a product that is still finding product-market fit, that iteration speed gap compounds. A team iterating on a web app can run four to six full product experiments in the time it takes to ship and propagate two updates to a mobile app.

Moz's 2025 research found that products with shorter feedback loops achieve product-market fit 2.3x faster than those constrained by release cycles. The App Store is the most common release cycle bottleneck a seed-stage team faces.

A progressive web app, PWA for short, is a web app that behaves like a native app on a mobile device. It can be added to the home screen, loads without a browser bar, works offline for certain features, and can send push notifications on Android (and, as of 2023, on iOS too).

For a large category of products, a PWA removes the need for a native app entirely:

• Content platforms (media, newsletters, learning tools)
• Marketplaces and booking platforms
• SaaS dashboards and productivity tools
• Community and social products that do not need deep device integration
• E-commerce where payments happen in-browser

PWAs do not work well when your product needs access to device hardware that browsers cannot reach: background GPS tracking, Bluetooth, near-field communication (NFC), or the full camera/video pipeline. That is a short list, but it matters. Delivery tracking, fitness hardware, and fintech products often fall into it.

The build cost difference is meaningful. A PWA adds roughly $2,000–$4,000 to a web app build. A full native iOS + Android build adds $20,000–$28,000 over a web-only MVP. For products where a PWA covers the needed functionality, it is the obvious path.

Web wins here decisively.

Web analytics tools give you second-by-second data on where users go, where they drop off, how long they spend on each screen, and what they click. You can run A/B tests on a web app and have results within 48 hours. Session recording, where you watch a replay of what a user did, works out of the box.

On mobile, data collection is structurally harder. Apple's App Tracking Transparency (ATT) framework, released in 2021 and tightened since, requires users to opt in to tracking. Roughly 75% of iOS users decline, according to AppsFlyer's 2023 benchmarks. Three out of four iOS users are invisible to your analytics from the moment they open the app.

For a product still searching for product-market fit, flying blind on 75% of your user base is a serious problem. You cannot improve what you cannot measure.

The practical implication: your first 1,000 users on web give you actionable data on all of them. Your first 1,000 users on iOS give you actionable data on roughly 250.

Four years ago, building for both iOS and Android meant writing two entirely separate apps, one in Swift for Apple devices, one in Kotlin for Android. That doubled the engineering cost and the maintenance burden.

Cross-platform tools like React Native and Flutter changed the math significantly. A single codebase can now produce apps for both iOS and Android, cutting the incremental cost of adding a second platform from 100% to roughly 30–40%.

For most consumer products in 2024, cross-platform is the right call if you need native at all. The performance gap between React Native and fully native has narrowed to the point where most users cannot tell the difference in day-to-day use. The 30–40% cost premium over a web-only build is a reasonable price for app store presence and push notification reach, if your product actually needs those things.

The founders who overpay are the ones who choose native iOS + Android for a product that a PWA would have served just as well.

This is the question most founders forget to ask, and it changes the economics dramatically.

Apple takes a 30% cut of every in-app purchase and subscription sold through the App Store (reduced to 15% for developers earning under $1M/year through the small business program). Google takes the same 30% on Google Play. If your product charges $30/month and 5,000 users pay through the App Store, Apple collects $9/user/month before you see a dollar. On web, payment processors like Stripe charge 2.9% + $0.30 per transaction, roughly $1 per user at that price point.

At scale, the platform tax is enormous. At 5,000 subscribers paying $30/month:

• Web (Stripe): ~$5,000 in processing fees retained by the platform
• App Store: ~$45,000 retained by Apple

For subscription products, that gap justifies acquiring users on the App Store (for discoverability) and pushing them toward web billing at the point of payment. Many B2C SaaS companies do exactly this, onboarding through mobile, billing through web.

For products where transactions are large and infrequent (marketplaces, B2B software), the App Store tax is less relevant because high-value transactions typically happen outside the app anyway. For subscription-heavy consumer products, the 30% take rate is a structural cost that needs to be modeled before you choose your primary platform.

AI-assisted development has been gaining real traction in engineering teams since 2023. GitHub's research published that year found developers using AI coding tools completed tasks 55% faster. The practical effect differs significantly by platform.

For web apps, AI tools have been effective for longer. The web is built on JavaScript and TypeScript, languages AI coding assistants were trained on extensively, and the patterns are highly repetitive. Login screens, dashboards, form validation, API connections: the standard plumbing of any web product is exactly where AI assistance is most mature and reliable.

For mobile development, the tooling is still catching up. React Native benefits substantially because it shares JavaScript's training corpus. Fully native Swift and Kotlin codebases see the smallest AI productivity gains of any platform.

The practical cost implication in early 2024: a web app gets the full AI productivity benefit. A cross-platform app captures roughly 60–70% of it. A native iOS + Android build captures 40–50%. That productivity gap is a meaningful part of why web apps built by AI-native teams like Timespade come in at $8,000–$12,000 while native mobile builds start at $28,000.

Marketplaces have two user types, suppliers and buyers, and those two sides often use different devices in different contexts.

Supplier onboarding (uploading inventory, setting availability, responding to bookings) almost always happens on a laptop. Buyers browse and purchase on mobile, but they start the discovery journey on Google, which means the product needs to rank in search, and web pages rank where apps do not.

A marketplace that launches mobile-first starts with a structural disadvantage in organic discovery. App Store search volumes are a fraction of Google search volumes for most product categories. Airbnb, Etsy, and DoorDash all had strong web presences before their mobile apps became the primary interface. The web built the audience; mobile retained it.

The rule of thumb: if your marketplace's core transaction can be completed in a browser and SEO is a meaningful acquisition channel, build web first. The one exception is on-demand products where the service happens in the physical world, delivery, rides, in-home services, and real-time GPS tracking is a core part of the product. Those require native mobile from the start.

For most marketplace founders, the right sequence is web MVP first, cross-platform mobile app at Series A. Timespade builds both, and the web codebase we deliver in week four can share components with the mobile app that follows, cutting the mobile build cost by 25–35% compared to starting from scratch.

---

The honest answer to the original question: build web first, unless your product genuinely cannot function without device hardware. The cost difference over two years is 3–4x. The data you collect at launch is richer. The iteration speed is faster. And for a seed-stage product still searching for product-market fit, those three factors matter more than having an app store listing.

If you want to pressure-test this decision against your specific product, book a free discovery call. We will look at your user acquisition model, your revenue model, and your feature list, and give you a concrete recommendation, including a cost estimate for both paths, within 24 hours.