One codebase, two stores
For most businesses, building separate iOS and Android apps doubles the cost without doubling the value. With React Native and Expo, one TypeScript codebase produces both apps. Native modules are used where they’re actually needed, and over-the-air updates let you fix bugs without waiting for store review.
When the right answer is different, I’ll say so. A content-heavy business may only need a well-built WebView app: your existing website inside a native shell, with native navigation, push notifications, offline fallbacks and store presence. I’ve shipped Android and iOS WebView apps for this. They reach the stores in weeks rather than months.
Apps that fit your existing product
Most of the mobile work I’m asked for is an app beside an existing system:
- Booking apps for clinics, studios and service businesses, connected to the calendar and payment system you already use.
- Companion apps for SaaS products, with the 20% of features users need on the go.
- Field apps for staff: inspections, check-ins, photos and offline forms that sync when back online.
Because I also build the backend and web side (see SaaS MVPs and API integrations), the app, the API and the admin panel are designed together. That avoids the slow back-and-forth you get when two vendors each own half the problem.
The parts that usually go wrong
Push notification setup, deep links, store review guidelines, signing certificates and release pipelines: this is where app projects stall. They’re all part of the fixed scope here. You end up with apps published under your own developer accounts and a documented release process you control.
What affects cost and timeline
App budgets are driven less by the number of screens and more by:
- Backend work. Is there already an API the app can use, or does one need building?
- Offline behaviour. Apps that must work without a connection and sync later need careful data design.
- Device features. Camera, Bluetooth, background location and payments each add native work and extra store review scrutiny.
- Accounts and payments. In-app purchases follow store rules that affect both design and revenue share.
A WebView-based app for an existing site can reach the stores in two to three weeks. A full React Native app with a new backend typically takes five to eight weeks for a focused first version. You get a fixed price after scoping, and future releases can be quoted separately or covered by a maintenance plan.
After launch
An app is never finished at launch. I set up:
- Crash reporting and analytics from day one, so you see which screens users rely on and where they drop off.
- Over-the-air updates, so fixes ship in hours instead of waiting days for store review.