From Web to Mobile Fast: Shipping Customer and Driver Apps with Expo

Many product teams already have solid Next.js web apps and suddenly need native mobile. Traditional estimates say weeks. We needed customer and driver apps for a food-delivery platform in a fraction of that time.

This is how we approached it: treat the web apps as the source of truth, use Expo + TypeScript + Expo Router, and let an AI coding agent with full-repo context generate and iterate — while humans review architecture and store readiness.

The starting point

We had two production web applications:

• Customer — browse stores, cart, checkout, order tracking, addresses, profile
• Driver — online toggle, deliveries, navigation, document upload, identity checks, earnings

APIs, types, and brand tokens already existed. The gap was mobile UX and store pipelines, not greenfield product design.

What we shipped

Customer app

• Home: categories, featured restaurants, nearby stores
• Store detail: menu, cart controls
• Checkout: fee breakdown, tip, place order
• Order tracking timeline
• Address book and profile

Driver app

• Dashboard with online/offline and earnings snapshot
• Active/history deliveries
• In-app Google Maps route with polyline
• Document upload (camera/gallery)
• Identity verification hooks
• Earnings breakdowns

Both apps share English/French i18n patterns with the web stack.

Why Expo Router helped

Expo Router's file-based routes mirror Next.js App Router mental models. Engineers who already knew the web tree could navigate the mobile tree without learning a second navigation paradigm. TypeScript kept API contracts honest across platforms.

Representative stack choices:

AI-assisted, not AI-unsupervised

The unlock was an agent that indexed the existing web codebases — not a chat window that only sees one file. Prompts stayed high-level ("implement screens from the web versions"); the agent pulled patterns, colors, and API clients from the repo.

Humans still:

• Reviewed auth and payment edges
• Fixed product decisions the model could not know
• Owned App Store / Play compliance and secrets

When packages were missing or context types drifted, the agent iterated quickly — but CI and smoke on device remained the truth.

Maps as a reality check

Driver navigation is a good quality bar: decode Directions polylines, show pickup/dropoff markers, offer "Open in Maps," and keep location permissions correct. If that screen works on a physical device, a lot of the stack is real — not a demo shell.

Time and cost framing

A traditional build for two feature-complete apps (setup, screens, API wiring, maps, uploads, i18n, CI) often lands in the multi-week range. With a strong web baseline and AI-assisted implementation, we collapsed the first production-ready cut dramatically.

We also preferred GitHub Actions + EAS/Fastlane cookbooks we control over paying for every build minute we do not need. Use managed build services where they save time; do not rent complexity you can script.

Takeaways

1. Mobile is faster when web already encodes the product.
2. Context beats clever prompts — agents that see your APIs and design tokens outperform blank-canvas generation.
3. Ship to TestFlight/Internal testing early — store pipelines catch what local Expo Go cannot.
4. AI multiplies senior judgment; it does not replace it on payments, PII, and release signing.

If you already run Next.js for customer and ops surfaces, Expo is a pragmatic path to native apps — especially when your APIs and domain model are already battle-tested on the web.