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 most solo founders building their first React Native app, six weeks is the optimistic floor and ten weeks is the realistic median. That is fine — you still ship same-quarter, and that is what matters.

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 roughly a thousand example repos you can paste into Cursor or Claude 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 with a long-context model, or Claude Code, will eat 60-70% of the boilerplate work — 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) — Apple sign-in is non-negotiable on iOS, plus email or magic link. Do not invent your own.
• Core CRUD screens (weeks 3-4) — every "create / read / update / delete" path of the main object.
• Payments (week 4) — wire up RevenueCat with a single subscription tier. More tiers is a v2 problem.
• Push notifications (week 5) — Expo handles most of this. Test on a real device, not a simulator.
• Settings, account deletion, support email link, terms and privacy URLs — all required for store review.

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. Run the headline and feature copy through /tools/instant-website-copy if you are stuck — it will give you a clean v1 you can rewrite into something honest. 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 usually takes one to three days but can stretch to a week if a reviewer flags something. Common rejection reasons in 2026: account deletion not implemented in-app, subscription terms not clearly disclosed, demo account credentials missing or not working, and any hint that you are using a webview as a primary surface. Most of these you can pre-empt by reading the App Review Guidelines once, slowly, before you submit.

Plan for two submission rounds. Most first apps get rejected at least once. While you wait, run a closed beta with twenty to fifty users — TestFlight on iOS, Google internal testing on Android. 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 honest budget and the honest bottom line

Realistic cash budget for a solo founder shipping a v1: $99 Apple developer fee, $25 Google Play fee, roughly $20-50 a month for Supabase or Convex, RevenueCat free up to a revenue threshold, Sentry and PostHog free tiers, and maybe $30-100 for icon and screenshot design if you outsource it. Total well under $500 for the first three months. The expensive thing is your time — guard it.

Six weeks is achievable if you have shipped a React Native app before, kept scope brutal, and used AI assistance well. Ten weeks is honest for a first-time mobile founder. 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. The founders who never ship are almost always the ones who spent week one picking a navigation library.