Skip to content
NEW v0.2.0 — Tracks, roadmaps and tiered stacks
STACK IT FIRST
Install the skills
Browse the site
02 · Mobile · Roadmap

Four questions, one stack.

A 4-question roadmap for choosing a mobile architecture an AI agent builds well in. Every answer is explained; every path ends on a stack.

Interactive roadmap

Stage 1 of 2Where are you?

Is the app already in the stores with paying users, or built by more than two people?

Before a store listing exists, you can ship a new build every hour and let the agent iterate on the whole app. After it, every release goes through review and users keep old versions for weeks, so the codebase needs versioned APIs and a test suite the agent runs first.
Stage 1 of 2

Where are you?

Mobile tiers are about release friction. A store review, a native module, or a second platform team each raise the cost of a wrong change, and the agent needs guardrails to match.
Stage 1 · Q1

Is the app already in the stores with paying users, or built by more than two people?

Why this matters

Before a store listing exists, you can ship a new build every hour and let the agent iterate on the whole app. After it, every release goes through review and users keep old versions for weeks, so the codebase needs versioned APIs and a test suite the agent runs first.

yes
Stage 1 · Q2

Do you need deep native capabilities, such as background sensors, heavy graphics or platform health data, or six or more engineers?

Why this matters

Cross-platform frameworks cover the vast majority of apps. What pushes a team past them is either a native capability that has no good bridge, or enough engineers that per-platform ownership becomes cheaper than fighting a shared layer. Either one means native modules or native apps, which the agent handles best when each platform is its own explicit project.

yes Tier

Scale

Native modules or native apps behind a shared contract, with per-platform ownership.
no Tier

Growth

Expo with EAS builds, a typed API you own, and E2E tests on real devices.
no Tier

MVP

Expo managed workflow, a hosted backend, over-the-air updates, no native code.
Stage 2 of 2

What are you building?

The profile decides whether the app is the product, a second face of a web product, or a focused utility. That sets how much backend the agent has to reason about at the same time.
Stage 2 · Q1

Is the app itself the product people open every day, such as a feed, media, or social?

Why this matters

Consumer apps live or die on scroll performance, media handling and push. Those are solved problems in the cross-platform ecosystem, but they must be chosen up front; retrofitting list virtualisation or image caching is exactly the kind of sprawling change an agent gets wrong.

yes Profile

Consumer

Content and social apps where the feed, media and notifications are the product.
no
Stage 2 · Q2

Is there a web product this app must mirror, with the same accounts and the same data?

Why this matters

A companion app should share types, validation and API clients with the web app, ideally from one monorepo. That lets the agent make a change once and see it in both places. If there is no web product to mirror, the app is a tool and can own its data locally.

yes Profile

Companion

The mobile face of an existing SaaS: same accounts, same data, shared types.
no Profile

Tool

Offline-first utilities where local data and one workflow matter most.
Result

Tier × profile.

Stage 1 picks the row, stage 2 picks the column. Each cell is a stack with a rule you can install.
Tier Consumer content & social Companion mobile face of a SaaS Tool offline-first utility
01 MVP Ship it Expo + Expo Router + Supabase 5/5 Expo in the web app's monorepo 5/5 Expo + SQLite, local-first 5/5
02 Growth Charge for it Expo + EAS + your own typed API 4/5 Expo + shared packages + EAS 5/5 Expo + SQLite + optional sync 4/5
03 Scale Run it for many React Native with native modules, or native apps behind one API 3/5 Expo with custom dev client in the platform monorepo 4/5 Native Swift and Kotlin behind one schema 3/5