Shipping a Mobile MVP Solo in 2026: A Realistic Timeline
The 6-week mobile MVP is real, but probably not for you
Every few months a thread goes viral about someone shipping a mobile app in six weeks. The thread is usually true. What it leaves out is that the founder had already built three apps before, knew exactly which boilerplate they were starting from, and had decided ruthlessly to cut anything that was not the core loop. For a solo founder building a first React Native app, six weeks is optimistic and ten weeks is more realistic. That is fine: you still ship within the quarter.
The reason mobile MVPs balloon past three months is almost never the code. It is App Store review, push notifications, payments, account deletion flows, and the slow death-by-edge-cases on iOS and Android together. The build is the easy part. Below is a timeline that bakes in the unsexy reality.
Stack: pick boring, pick fast
In 2026 the default solo-founder stack is Expo plus React Native, with Supabase or Convex for the backend, RevenueCat for subscriptions, Sentry for crash reporting, and PostHog or Amplitude for analytics. This combination is boring on purpose. Every piece has a free tier, a managed dashboard and plenty of public examples to learn from when you get stuck. Resist the urge to swap any of them for something cooler. Cool stacks are how indie projects die at week four.
If you are not already a mobile developer, lean hard on AI assistance. Cursor or Claude Code can take on much of the boilerplate: navigation setup, list screens, form validation, API client glue. Do not let it touch payment, auth, or storage flows without you reading every line. The cost of an AI-introduced subscription bug is much higher than the time saved.
Weeks 1-2: design and the spike
The first two weeks are spent on three things, in parallel where possible. First, lock the core loop. Write the one user journey that the app exists to do, in three to five screens, and refuse to design anything outside it. Second, do the design in Figma at the screen level, not the pixel level: boxes, labels and stack order. Polish comes at the end. Third, run a technical spike: build the riskiest screen first, end to end, with real data flowing. That is the screen that proves whether your stack assumptions hold.
Do not start with auth or onboarding. Start with whatever the user is paying you for. If that does not feel achievable in week one, the scope is too big and you should cut, not push harder.
Weeks 3-5: build the actual app
This is the middle of the project and the place AI-assisted dev pays the most. With the core loop already proven, the work is mostly filling in: list screens, detail screens, settings, edit flows, empty states, loading states, and the small connective tissue that makes the app feel like a product instead of a prototype.
- Auth (week 3): if you offer Google or Facebook sign-in on iOS, Apple's review guidelines (section 4.8) also ask for a privacy-focused login option, and Sign in with Apple is the simplest way to meet that. Add email or a magic link. Do not build your own.
- Core CRUD screens (weeks 3-4): every create, read, update and delete path of the main object.
- Payments (week 4): wire up RevenueCat with a single subscription tier. More tiers can wait for v2.
- Push notifications (week 5): Expo handles most of this. Test on a real device, not a simulator.
- Settings, in-app account deletion, a support email link, terms and privacy URLs: store review checks all of them.
Week 6-7: polish, edge cases, and the landing page
By the end of week five you have something that works. It does not yet feel like a product. Week six is for the things that turn a working app into one a stranger would not refund: real loading skeletons, error toasts with useful messages, offline handling on the core screens, haptics on key actions, dark mode if your audience expects it, and an empty state for every list that gives the user a next step.
In parallel, build the landing page. App Store review will ask for a marketing URL, and you need a place to send traffic anyway. A single-screen Framer or Astro page is enough. If you are stuck, run the headline and feature copy through /tools/instant-website-copy to get a first draft you can rewrite. The landing page is also where you collect TestFlight or beta signups, which becomes useful in week seven.
Week 8-10: review, beta, and the part nobody warns you about
App Store review often takes a day or two and can take longer if a reviewer flags something. Points that commonly cause a rejection: account deletion missing from the app, subscription terms not clearly disclosed, missing or broken demo account credentials, and an app that is little more than a web view. Most of these you can pre-empt by reading the App Review Guidelines once, slowly, before you submit.
Plan for two submission rounds, since a first rejection is common. While you wait, run a closed beta with a few dozen users: TestFlight on iOS, internal testing on Google Play. The point of the beta is not to find bugs (you will), it is to watch real people use the app and discover which screens they do not understand. That is the data you cannot get from your own usage.
The budget and the bottom line
The fixed costs are small: the Apple Developer Program costs $99 a year and a Google Play developer account $25 once (see the sources below). Supabase or Convex, RevenueCat, Sentry and PostHog all have free tiers that cover a v1; add a paid backend plan when usage requires it, and a small budget for icon and screenshot design if you outsource it. The expensive part is your time, so guard it.
Six weeks is achievable if you have shipped a React Native app before, kept the scope tight and used AI assistance well. Ten weeks is more realistic for a first mobile app. Either way, the shape of the work is the same: design, spike, build the core loop, fill in the connective tissue, polish, ship to review, beta, iterate. Spending week one on picking a navigation library is a reliable way not to ship.