We build iPhone and Android apps for companies that need a product in both stores and a team that can keep it healthy after launch. Most of our mobile work is a React Native or Flutter app on one codebase. We write native Swift and Kotlin when the product leans on the platform itself: camera pipelines, background work, system widgets, hardware.
This page explains how we choose between those routes, what a mobile project involves from first sprint to store release, and what makes the bill grow. Platform detail lives on the pages for iOS, Android, React Native and Flutter.
What do we build?
Four kinds of project cover most of what we take on.
- New apps for a funded product. Consumer apps, marketplaces, booking flows and member apps, usually with a backend we build or extend in the same project.
- Companion apps for a web product. A SaaS platform gets a phone client for the tasks people do away from a desk: approvals, field data capture, notifications.
- Consolidation of two codebases. A company with separate iOS and Android apps, two teams and drifting features moves to one code path.
- Rescue and upgrade work. Apps that no longer build on the current Xcode or Android Gradle plugin, crash on new OS releases, or got rejected by a store review.
Native or cross-platform: how do we decide?
We decide on the product, not on preference. The questions that settle it:
| Question | Points to cross-platform | Points to native |
|---|---|---|
| How much of the app is forms, lists, maps, chat and payments? | Most of it | Little of it |
| Does it depend on advanced camera, AR, Bluetooth stacks or long background tasks? | No | Yes |
| Who maintains it after launch? | One small team | Separate platform specialists |
| Does the web team write React or TypeScript? | Yes, React Native reuses that skill | Not relevant |
| Must a custom design look identical on both systems? | Flutter fits well | Native fits when each system should feel its own |
| Is time to first release the main risk? | Yes | No |
Mixing both routes is common. A cross-platform shell with a native module for one demanding feature avoids a full native build and keeps the tight part tight. Our React Native vs Flutter comparison goes through the two frameworks in detail, and the platform pages explain when we pick Swift or Kotlin outright.
How does a mobile project run?
Every project follows the same five steps.
- Discovery and scope. We list the user journeys, name the platform capabilities the app needs, and mark integrations. This produces the feature list that estimates are built on.
- Design. Flows and screens follow Apple’s Human Interface Guidelines and Material Design where they apply. If you need a designer on the team, see mobile app designers.
- Build in short increments. You get a build on your phone at the end of each increment, delivered through TestFlight and Google Play internal testing.
- Hardening. Device testing, performance profiling, accessibility checks and store compliance work.
- Release and watch. Staged rollout, crash monitoring, and a short period where the same engineers who shipped it watch the numbers.
How do we test and release on real devices?
Simulators catch logic errors. Real phones catch the rest: thermal throttling, slow storage, odd keyboards, poor networks, notches and cutouts. We test on a device matrix chosen from your analytics or, for a new product, from the markets you launch in, covering older and mid-range Android hardware as well as recent iPhones.
Automated checks run on every pull request: unit tests, component tests and end-to-end flows on the critical paths such as sign-up, payment and the main task of the app. Release builds are produced by a pipeline, usually Fastlane or EAS, so signing, versioning and store upload do not depend on one person’s laptop.
Both stores review submissions. Apple reviews every app and update, and says it reviews most submissions within 48 hours. Google Play runs its own checks and has testing track requirements for some developer accounts. We plan for review time in the release schedule and prepare the items that most often cause rejections: a privacy policy link, demo credentials for reviewers, accurate screenshots and purpose strings for permissions.
What drives the cost of a mobile app?
We do not publish a price list because scope moves the number more than anything else. The drivers, roughly in order of impact:
- Feature depth. Real-time sync, payments, maps with live tracking, video and offline behavior each add engineering and test surface.
- Backend work. An app on top of an existing API costs less than one that needs a new API, database, authentication and admin panel.
- Platform route. One codebase for both stores generally costs less than two native builds; the gap narrows as native-only features accumulate.
- Design depth. A standard component set is quick. Custom motion and a bespoke design system take design and front-end time.
- Compliance and integrations. Health data, payments and identity providers add architecture and review work.
- Ownership after launch. OS releases and library updates arrive every year, so maintenance is a recurring line.
Our mobile app cost guide lays out ranges by app type. We give a written estimate after a short scoping call, with the assumptions listed.
What have we shipped?
Two projects show the two common routes to market.
A European fitness healthtech brand at Series-C+ ran separate iOS and Android codebases. We consolidated them into one React Native codebase with a shared component library and a single release pipeline. Cold start fell to 1.4s from 3.8s, and release cycle time dropped by about 60%. Read the fitness app case study.
An APAC seed travel startup needed both stores within a quarter. We shipped a React Native MVP, 8 weeks from kick-off to both app stores. The case notes the build cost was about 40% lower than dual native, an estimate and not audited spend. See the travel MVP case study.
How can you work with us?
Three models, depending on how much of the work you want to own:
- Project delivery. We run discovery through release for a fixed scope.
- Dedicated team. A dedicated mobile app development team works inside your roadmap.
- Individual engineers. Hire mobile developers to join your team, at $50 to $150 per hour depending on seniority and role.
Send us the idea, the platforms and the date you care about, and we reply with the questions a scoping call needs to answer.
