The Solo Developer's Tech Stack for Building a Mobile App in 2026

The constraint that changes everything

Most tech stack advice is written for teams. Teams can absorb complexity. They can split iOS and Android between two people, dedicate someone to DevOps, hire a designer who owns the component library. You can't do any of that.

When you're solo, the right tech stack isn't the one with the best benchmarks or the most elegant architecture. It's the one that lets you ship the most features per hour of work. That's a different optimization problem, and it produces different answers than what you see on Hacker News.

I've looked at what solo developers who actually make money from their apps tend to converge on. The pattern is consistent: they pick boring tools, minimize moving parts, and spend their complexity budget on the product instead of the infrastructure.

Cross-platform vs native: the real tradeoff

This is the first decision and the one that locks in the most downstream choices. In 2026, your realistic options are React Native, Flutter, SwiftUI (iOS only), Kotlin Multiplatform, and building a web app with a wrapper (Capacitor/PWA).

If you're building for both iOS and Android, which you probably should be if you're targeting any market outside Japan, cross-platform is the only sane choice for a solo developer. Writing two native codebases doubles your maintenance burden forever. That tax compounds.

React Native is where most solo devs end up. The ecosystem is mature, the library coverage is wide, and if you already know JavaScript or TypeScript, you skip months of ramp-up. Expo has gotten good enough that you rarely need to eject or write native modules anymore. The new architecture (Fabric, TurboModules) closed most of the performance gap that people used to complain about.

Flutter is the main alternative. The rendering engine gives you more pixel-level control, which matters for custom UI-heavy apps (think Figma-style tools or games). But Dart is a smaller ecosystem. When you need a library for some niche integration, you're more likely to find it in npm than in pub.dev. For a solo dev, library availability directly converts to hours saved.

Kotlin Multiplatform is interesting if you're coming from Android and want to share business logic while keeping native UI. But the iOS story still requires you to write SwiftUI. You end up maintaining two UI layers, which is the thing you were trying to avoid.

SwiftUI only makes sense in one specific case: you're building a utility app for a market where iOS dominates (Japan, for instance, where iPhone market share is above 65%). Our geo-arbitrage scanner shows plenty of opportunities in iOS-heavy markets where ignoring Android is a legitimate strategy, not just laziness.

Web apps with Capacitor are underrated for content-based apps, reference tools, and anything where you don't need heavy device integration. You write a responsive web app, wrap it, and ship. The ceiling is lower (no smooth 60fps gestures, limited background processing), but the speed to market is unbeatable. Some of the web-to-app opportunities we've identified are perfect candidates for this approach.

My general recommendation: React Native with Expo unless you have a specific reason not to. It's not the sexiest answer. It's the one that gets you to market.

Backend: less is more, literally

The biggest trap for solo developers is building too much backend. You don't need a microservices architecture. You don't need Kubernetes. You probably don't even need a traditional server.

Supabase handles auth, database, storage, and realtime for most indie apps. It's Postgres underneath, which means you get a real database with real SQL, and you can always migrate off if you outgrow it. The free tier is generous enough to get you through launch and your first few hundred users.

Firebase still works. Firestore's document model is easier to get started with than SQL, and the realtime sync is battle-tested. The downside is vendor lock-in and a pricing model that gets expensive at scale in ways that are hard to predict. I've talked to solo devs who hit unexpected bills because they didn't realize how Firestore charges for reads.

Serverless functions (Vercel, Cloudflare Workers, AWS Lambda) fill the gap for anything Supabase or Firebase can't handle directly. Payment webhooks, third-party API integrations, scheduled jobs. Keep them thin and stateless.

What you want to avoid: running your own server. The moment you have a VPS to maintain, you're spending time on uptime monitoring, security patches, and SSH debugging instead of building features. Managed services exist specifically so solo developers don't have to do ops.

The pattern I see in successful solo apps: Supabase or Firebase for the core data layer, one or two serverless functions for custom logic, and nothing else. If your backend architecture needs a diagram to explain, it's too complicated for one person.

Payments: Stripe and RevenueCat, then stop thinking about it

For in-app purchases and subscriptions on iOS and Android, RevenueCat is the answer for 95% of indie apps. It abstracts the App Store and Play Store billing APIs, handles receipt validation, manages subscription status, and gives you analytics. The free tier covers up to $2,500/month in tracked revenue.

Implementing in-app purchases natively is one of those things that sounds straightforward until you're debugging why a subscription renewal failed on a specific device running iOS 16.3 with a non-US Apple ID. RevenueCat has already hit those bugs and fixed them. Your time is better spent on deciding what to charge than on the plumbing.

If your app also has a web component (and it probably should, even just for marketing), Stripe handles that side. Stripe Checkout gets you a payment flow in an afternoon. The combination of RevenueCat for mobile and Stripe for web covers almost every monetization model we discuss in our revenue models guide.

Analytics: what to track when you can't track everything

Big companies have analytics teams. You have yourself and whatever you can glance at during lunch. The goal isn't comprehensive data. It's knowing three things: are people finding the app, are they using it, and are they paying.

PostHog or Mixpanel for product analytics. PostHog is open source with a generous free tier. Mixpanel is more polished. Either one gives you event tracking, funnels, and retention curves. Pick one and instrument your core flows: onboarding completion, feature usage, and the path to purchase.

RevenueCat's dashboard covers revenue metrics (MRR, churn, trial conversion). Don't build your own revenue dashboard. Don't pull this data into a spreadsheet. Just check RevenueCat.

App Store Connect and Google Play Console give you download numbers, crash reports, and review trends. Check them weekly, not daily. Daily checking breeds anxiety without actionable insight.

The mistake I see solo devs make is tracking too much. Twenty custom events, elaborate user properties, complex funnels. Then they never look at any of it because it's overwhelming. Five to ten well-chosen events tell you more than a hundred poorly chosen ones.

AI tools: where they actually help a solo dev

I'm going to be specific here because the general "AI is changing everything" take is useless.

Code generation (Cursor, GitHub Copilot, Claude) saves real time on boilerplate. Setting up a new screen, writing CRUD operations, generating test cases for edge conditions. The key is treating suggestions as drafts, not finished code. Review everything. The bugs AI introduces are the subtle kind that pass tests and break in production.

Design is where AI helps solo devs the most, because design is the skill most of us are weakest at. Tools like v0 (Vercel) generate reasonable UI components from descriptions. You won't get a great design, but you'll get a functional one, and functional beats ugly-but-I-didn't-have-time.

Content for your App Store listing, marketing pages, and ASO is another legitimate use. Generate drafts, then rewrite them in your voice. The draft-to-edit workflow is faster than staring at a blank page.

As an in-app feature, AI is powerful but expensive. If your app uses LLM calls, build tight usage limits and cache aggressively. I know solo devs who launched AI features with no rate limiting and got a $400 OpenAI bill in the first week. Set a per-user daily cap. Use smaller models where you can. Our trends analysis found that the AI apps winning in 2026 are the narrow, specific ones, not the generic chatbot wrappers.

CI/CD and distribution

EAS Build (Expo Application Services) handles iOS and Android builds in the cloud. This matters more than it sounds. Building locally means maintaining Xcode, Android Studio, Java versions, and signing certificates. EAS takes that off your plate. The free tier gives you enough builds for an indie cadence (a few per week).

GitHub Actions handles anything else: running tests, deploying your web components, triggering EAS builds on push. A basic CI pipeline takes an hour to set up and catches the embarrassing bugs before your users do.

TestFlight and Google Play internal testing are your staging environments. Don't skip this step. Ship to testers first, even if your only tester is your partner or a friend who agreed to install the app. Fresh eyes catch things you stopped seeing months ago.

Over-the-air updates (Expo Updates, CodePush) let you push JavaScript changes without going through app review. Use this for bug fixes and minor tweaks. Don't use it to ship major features, because users expect app updates to come through the store.

The stuff people forget

A few things that don't fit neatly into categories but trip up solo devs regularly.

Error tracking. Sentry or Bugsnag. Not optional. You will ship bugs. The question is whether you find out from a crash report or from a one-star review. Sentry has a free tier that works for indie apps.

Push notifications. Firebase Cloud Messaging (FCM) for Android, APNs for iOS. If you're using Expo, their push notification service wraps both. Don't build notification infrastructure from scratch. You'll spend a week on it and it still won't handle edge cases like token rotation and silent pushes correctly.

Localization infrastructure. Even if you launch in one language, set up i18n from day one. Extracting hardcoded strings later is painful in a way that's hard to appreciate until you're doing it. Our localization guide covers the technical and cultural sides. The technical part (setting up string files) takes an afternoon. The cost of retrofitting it later takes weeks.

Terms of service and privacy policy. You need both for App Store submission. Don't write them yourself. Use a generator (Termly, iubenda) or adapt a template. This is not where your time should go, but it's a submission blocker if you skip it.

A landing page. Even if your app lives in the App Store, you need a web presence for SEO, for linking from social media, and because some percentage of your users will Google your app name before downloading it. A single page on your domain with your app's value prop, screenshots, and a download link. Next.js or Astro, deployed on Vercel. Takes a few hours.

A reference stack

If I were starting a new indie app today and wanted to ship fast while keeping things maintainable, here's what I'd pick:

Total recurring cost at launch: roughly $0/month. Supabase free tier, PostHog free tier, RevenueCat free tier, Vercel free tier, Sentry free tier, EAS free tier. You can build and launch a real app without spending anything on infrastructure until you have paying users.

That's worth sitting with for a second. The cost of building a mobile app in 2026, if you already know how to code, is essentially your time. The infrastructure is free until it doesn't need to be.

What I'd skip

GraphQL. REST or Supabase's client library is simpler for a solo dev. GraphQL adds tooling complexity (schema management, code generation, caching) that pays off at team scale but costs you at solo scale.

Monorepo tools. Turborepo, Nx, and similar tools solve problems that appear when multiple teams work in the same codebase. If you're one person, a single repo with clear folder structure is fine. Don't add tooling to manage complexity you don't have.

Custom design systems. Use a component library (React Native Paper, Tamagui, NativeWind) and customize the theme. Building components from scratch is satisfying and slow. When you're looking at our rising niche scanner and spot an opportunity, you want to move fast. A custom Button component with perfect animations is not what gets you there.

Kubernetes, Docker in production, or any container orchestration. If the phrase "cluster management" appears in your solo dev workflow, something has gone wrong.

Building your own auth. Use Supabase Auth, Firebase Auth, or Clerk. Auth has a surface area of security edge cases (token refresh, session invalidation, OAuth flows, magic links, MFA) that takes months to get right. Someone else has already done it.

The tech stack trap

I want to end with something I've noticed after looking at hundreds of indie apps through our scanners: the apps making money are rarely the ones with the most impressive tech stacks. They're the ones that solved a specific problem for a specific group of people and then iterated based on feedback.

The tech stack is the means. The product is the end. It's possible to spend so much time choosing and configuring tools that you never actually build the thing. I've seen people debate React Native vs Flutter for weeks when the app they want to build is a simple list with a search bar.

If you're trying to validate an app idea, the fastest path is a working prototype, not a perfect architecture. Use whatever you already know. If you know React, use React Native. If you know Dart, use Flutter. If you know Swift, build for iOS first and worry about Android when you have revenue.

The best tech stack for a solo developer is the one that disappears. The one where you stop thinking about infrastructure and start thinking about whether the thing you're building is something people actually want. The MVP guide covers how to figure that out. The tech stack just needs to not get in the way.