Mobile Growth: charge for it.
- Users
- Hundreds to tens of thousands
- Team
- Two to five engineers, each with agents
You are here if
- Users keep old versions for weeks after a release
- A store rejection costs you a launch date
- You need analytics, crash reporting and push that you own
- The backend is your code, shared with a web product or not
Growth on mobile is about release discipline more than architecture. The app is still one Expo project, but the backend is now yours, the API is versioned, and a Maestro flow runs on a real device before every build. The agent keeps working in the JavaScript layer; native changes go through a config plugin and a full build, and are rare by design.
What changes when you leave this tier: a native capability with no good bridge, or enough engineers that per-platform teams become cheaper than a shared layer. Until then, stay cross-platform.
Consumer · content & social
Expo + EAS + your own typed API
The same Expo app, now behind a versioned API you own, with device tests and crash reporting before every build.
The stack
- Framework
- Expo + Expo Router, EAS Build and Update
- Data
- Your API (Hono or NestJS) over Postgres, with a CDN for media
- Auth
- Your provider, with refresh tokens handled in one place
- Hosting
- EAS for builds and updates, store releases on a cadence
- Also
-
- Sentry for crashes, PostHog for analytics
- Maestro flows on real devices in CI
- Push through your API, not straight from a hosted backend
Why agents do well here
4/5- A versioned API with generated types lets the agent change the backend without breaking the users still on last month's build.
- Maestro flows are YAML the agent can read and extend, turning "does the feed still scroll" into a check it runs itself.
- Everything is still TypeScript; native changes go through config plugins and remain rare.
Avoid at this tier
- Breaking API changes; add fields, never remove them, until the old version's usage is zero.
- A custom native module for performance you have not measured with the profiler.
- Shipping a store build without the Maestro flows passing.
Companion · mobile face of a SaaS
Expo + shared packages + EAS
The monorepo grows up; the mobile app gets its own release pipeline while still sharing every type with the web app.
The stack
- Framework
- Expo + Expo Router in the product monorepo
- Data
- The product API, consumed through a shared generated client
- Auth
- The product's provider with native SDK and biometric unlock
- Hosting
- EAS Build and Update with a release channel per environment
- Also
-
- Shared design tokens through NativeWind
- Maestro flows for the mobile-only paths
- Deep links mapped to the web app's URLs
Why agents do well here
5/5- The shared client and schema packages mean the agent's backend change surfaces as a type error in the mobile app before anyone opens a phone.
- Deep links that mirror web URLs let the agent reuse the web app's route knowledge for mobile navigation.
- Release channels per environment make it safe for the agent to push updates to staging on every merge.
Avoid at this tier
- Diverging the mobile data model from the web one; keep one schema package.
- Rebuilding web features on mobile because they exist; keep the phone flows deliberate.
- Native modules that only one platform needs, unless it is the product.
Tool · offline-first utility
Expo + SQLite + optional sync
Local-first stays the default; sync, accounts and paid tiers are added as separate features with their own boundary.
The stack
- Framework
- Expo + Expo Router, EAS Build and Update
- Data
- expo-sqlite with Drizzle on device; PowerSync or a small Hono API for sync
- Auth
- Only for sync and purchases
- Hosting
- EAS; RevenueCat for in-app purchases
- Also
-
- NativeWind
- Maestro flows for the core workflow
- Sentry
Why agents do well here
4/5- Keeping local data as the source of truth means the agent can test the whole workflow without a network.
- Sync as a separate feature with its own module keeps the hardest code in one place the agent can read in isolation.
- Purchases through RevenueCat give the agent a documented SDK instead of two platforms' store APIs.
Avoid at this tier
- Rewriting the app around a server database when sync is requested; add sync to the local one.
- Handling store receipts yourself.
- Sync engines you cannot debug from the client; prefer ones with visible queues.