Most SaaS products do NOT need a mobile app. Most founders who build one regret it within 18 months. This is the contrarian framework for figuring out whether you’re the exception or the rule.
Methodology. This guide draws on App Store fee structure documented by Apple’s App Store guidelines and PWA install-rate data published by Google’s web.dev PWA documentation. We have shipped one native app and three progressive web apps. How we research.
Mobile apps are an enormous tax on solo founders. Build one only when the product’s primary action genuinely happens on a phone — and even then, ship a PWA first.
Before we get to the cases where a mobile app is justified, you need to internalise what you’re actually signing up for. The honest cost ledger is brutal, and most founders never run the numbers before they start.
App Store fees of 15–30%. Apple takes 30% of the first year of subscription revenue from any developer making over $1M, and 15% afterwards. Per Apple’s small-business program, you get 15% from day one if you make under $1M. Either way, it’s a permanent revenue tax that doesn’t exist on your web product. On a $20/month subscription, you’re handing Apple between $36 and $72 per year per customer.
A separate codebase or a React Native learning curve. Even with React Native or Flutter, mobile is not just “your web app on a phone.” You’ll spend two to three months learning navigation libraries, native modules, push notification plumbing, and the build pipeline. If you go fully native, double it.
App Store review delays. Submit on Monday, ship on Friday — that’s the optimistic case. The pessimistic case is a rejection over a UI guideline you’ve never heard of and a two-week appeal cycle. Compare this to your web product, where you push to production five times a day.
Separate analytics, separate support, separate everything. Mobile users have their own crash reports, their own bug reports, their own UX expectations, and their own onboarding patterns. You’re not adding a feature; you’re adding a second product to support.
Mobile-specific support load. “Why doesn’t the iPad version work?” “Why doesn’t Face ID work?” “Why doesn’t the dark mode match?” The questions multiply. Solo founders without a support team feel this immediately.
With those costs in mind, here are the only four scenarios where the math actually works for a solo founder. If you can’t cleanly tick at least one, the answer is no.
Tracking apps (workouts, food, mood), capture apps (receipts, voice memos, photos), and in-the-moment apps (point-of-sale, dispatch, navigation) all require the phone’s sensors, camera, or location to be useful. If the action you’re selling cannot happen on a laptop, you need an app. This is the only truly unambiguous case.
If every direct competitor has an app and prospects ask about yours during sales calls, the absence is now a deal-breaker. This is rare in B2B; common in consumer categories like fitness, finance, and productivity. Verify it’s actually costing you deals before you commit.
If 40%+ of your sessions are already coming from phones, that’s a strong signal that the mobile experience matters. Note the threshold: not 10%, not 20%. Below 40%, you’re solving a niche use-case at full app cost.
Push notifications, camera capture, bluetooth, background location, biometric auth — if your product’s differentiation requires one of these, you genuinely need an app. Note that web push notifications work on Android and Chrome on Windows/macOS; the case is much weaker for Apple-heavy audiences.
Before you build native, you should have ruled out the alternatives. For 80% of SaaS products, one of these gets you 90% of the value at 10% of the cost.
Progressive Web Apps (PWAs) with install prompts. A PWA installs from the browser, lives on the home screen, works offline, and bypasses the App Store entirely. Per Google’s web.dev research, install prompts on engaged users convert at 5–15%. The codebase is your existing web app. The build cost is days, not months.
Mobile-first responsive design. If your web app feels like a mobile app on a phone — large tap targets, no horizontal scroll, no hover-only interactions — users won’t notice it’s not native. This is the default move and the cheapest investment with the best return.
Web push via the Push API. Web push works on Android, Windows, and macOS Chrome out of the box. Apple added support to iOS Safari in 2023 (with the caveat that the user has to install the PWA first). For most SaaS notification use cases, this is sufficient.
If you’re building solo, see our solo founder tech stack guide for PWA-friendly toolchains we’ve actually shipped with.
Decided you’re genuinely in one of the four cases? Here’s the order of operations that minimises wasted work and gives you off-ramps at each step.
The graduated path matters because each step is reversible. Building a full native app from day one makes every product decision permanent. Wrapping a PWA gives you four off-ramps.
The following are the most common reasons solo founders start building a mobile app — and the reasons not to. If your motivation matches one of these, walk away from the laptop and review your core SaaS metrics first.
If you’ve read this far and you can clearly tick one of the four justifying cases without flinching, build the PWA this week. If you can’t, the right call is to invest the same time in the web product. Make the mobile-web experience excellent, ship a PWA install prompt, and add native only when the metrics force the question.
The mobile-app decision is one of the few in solo SaaS where the wrong answer can sink the company. Twelve months building a native app while the core product stagnates is a death spiral. Twelve months making the web product genuinely great is, almost always, the higher-leverage choice. For more on the kind of build pace that compounds, see our guide on how to build SaaS with Claude.
The stack, prompts, pricing, and mistakes to avoid — for solo founders building with AI.