AI ERP with agents inside the systems you run
AI phone and voice agents for real calls
LLM.coPrivate, self-hosted LLM deployments
Legal AI infrastructure for firms
AI RFP discovery and response drafting
Automatic.coBusiness process automation
CyberAttack.aiThreat detection and defense
Secure AI virtual data rooms
8–14 wks
First release
Both stores, one v1
Scoped
Typical build
Depends on native vs. shared code
~50%
Of lifetime cost
Spent after v1 ships, not before
100%
Code and store accounts yours
From the first commit
The framework decision
Native, React Native, Flutter, or no app at all
Every one of these is a legitimate choice for the right project and a mistake for the wrong one. The decision turns on your team, your roadmap, and how much of the experience depends on the platform underneath it — not on what shipped a conference talk this year, and not on which framework a previous vendor happened to know.
Native (Swift and Kotlin)
Full access to the platform: camera pipelines, background location, ARKit, whatever capability ships first on a new OS release. It costs two codebases and two release trains, and it is the right call when a platform-specific capability is the product, not a feature bolted onto one.
React Native
One JavaScript codebase covering both platforms, with an escape hatch to native modules where you need one. It suits teams with existing web or React engineers and products where the interface matters more than squeezing the last frame out of the GPU. Heavy animation and background work still tend to need a native module eventually.
Flutter
Genuinely closer to native performance than React Native on graphics-heavy screens, at the cost of a smaller hiring pool and a language — Dart — your existing team probably does not know. Worth it when the UI is unusually custom and pixel-identical rendering across both platforms matters more than reusing the skills you already have in-house.
Mobile web or a PWA
The honest answer when the app's job is to display information or take a form, not to use the camera, run offline, or send push notifications a user actually wants. It skips app store review entirely, updates the moment you deploy, and costs a fraction of either app. Building an app anyway because a website feels less impressive is the most common overspend in this category.
Webview hybrids (Capacitor, Cordova)
A website wrapped in a native shell to get a store listing and a handful of device APIs — camera, push, local storage — without writing a mobile codebase. It is honest for a content-driven app that mainly needs an icon on the home screen, and a poor choice the moment the interface needs to feel like the rest of the OS, because a webview never quite does.
Reusing a web codebase deliberately
Teams already running Next.js or a similar React stack can sometimes share business logic and API clients between the web app and a React Native client without sharing the UI layer. This is a genuine cost saving when it is planned from the start, and a source of awkward abstractions when it is retrofitted onto a web app that was never meant to be shared.
None of these decisions are free to reverse later. Moving from React Native to native, or from a wrapper to a real mobile codebase, is closer to a rebuild than a refactor, which is why the decision belongs in week one and not somewhere around week eight when the first performance ceiling shows up.
What it costs
Mobile app development cost, by what you are actually building
Real ranges for apps we have actually shipped. The variable that moves a quote is not screen count — it is how much of the app has to be native, how many backend integrations it depends on, and whether it needs to work offline. Design work, if you do not already have it, is usually a separate line rather than something buried inside these numbers.
| Build | Commitment | Timeline | What's included |
|---|---|---|---|
| Single-platform MVP | Fixed scope | 6 – 10 weeks | One platform (iOS or Android), one core workflow, backend, and basic push notifications. |
| Cross-platform build (React Native) | Fixed scope | 8 – 12 weeks | Both stores from one codebase, standard device APIs, and offline caching for the core screens. |
| Native iOS + Android | Fixed scope | 12 – 18 weeks | Two native codebases, platform-specific UI and performance work, and full offline sync. |
| Migration off a webview hybrid | Fixed scope | 8 – 14 weeks | Rebuilding a Cordova or Capacitor app in React Native or native once the wrapper stops feeling acceptable to users. |
| App store rescue or resubmission | Fixed scope | 1 – 4 weeks | A rejected or stalled submission diagnosed and fixed against Apple's or Google's actual review notes, not guesswork. |
| Ongoing OS maintenance | Ongoing retainer | Ongoing | Yearly OS upgrades, deprecated API replacement, crash monitoring, and the SDK bumps both stores eventually require. |
Ranges assume US-based senior engineers and include QA, device testing, and app store submission rather than quoting them separately. A quote well under these bands is usually missing offline handling, push infrastructure, or the maintenance year that follows launch — and that gap does not disappear, it just shows up later as a change order.
Offline, sync, and push
The parts that make an app feel native instead of a website in a frame
None of this shows up in a wireframe, and all of it shows up in the first week of real usage — usually as a support ticket about data that 'disappeared' when it was really just unsynced.
Offline-first is a design decision, not a feature flag
A local database on the device — SQLite, WatermelonDB, or Realm depending on the stack — with a defined rule for what happens when two edits collide. Deciding whether the server or the device wins, and when, has to happen before the first screen is built, because retrofitting it later means rebuilding the data layer.
Conflict resolution is the part nobody wants to decide
Last-write-wins is simple and wrong for anything a user would notice losing, like a form they filled in twice on two devices. A CRDT-based approach or field-level merging costs more to build and is the honest answer once more than one device can edit the same record, which is most business apps within a year of launch.
Push notifications need a backend, not just a library
APNs for iOS and FCM for Android both require a service that tracks device tokens, handles token rotation when a user reinstalls, and retries delivery. The library on the client is the easy 10 percent; the token lifecycle and the send pipeline are the other 90.
Background execution is the platform's decision, not yours
iOS suspends background work aggressively to protect battery, and a sync job you assumed would run every fifteen minutes may run once an hour, or not at all, if the OS decides the app is not in active use. Design for eventual sync on foreground, not for a background job you cannot guarantee runs.
Testing offline behavior means simulating a bad network, not no network
The failure that actually happens in the field is a flaky subway connection or a spotty warehouse Wi-Fi, not a phone in airplane mode. Test against throttled and intermittent connectivity, because a sync engine that only handles the clean on/off case will misbehave on the messy case users actually hit.
Store review
App Store and Play Store review as a schedule risk, not a formality
Review is not a rubber stamp, and treating a launch date as fixed before the app has actually been through it is how a shipped build becomes a missed date. It is also not a one-time event — every update after v1 goes through the same gate, on the same timeline.
Apple's review is a real gate
Typically 24 to 48 hours, but a rejection resets the clock, and the reasons range from a broken login flow to subscription-language guidelines that have nothing to do with your code. Budget a buffer week before any date you have promised to a stakeholder.
Google's review is faster and less forgiving on data
Play Store review often clears in hours, but its data safety declarations and permission justifications are checked more literally than Apple's, and a mismatch between what you declare and what the app actually collects gets a build pulled after launch, not before it.
Staged rollouts exist for a reason
A phased rollout to a percentage of Android users, or a TestFlight beta ahead of the public release, catches the crash that only shows up on a specific device or OS version. Skipping this step to save a week is the most common cause of the one-star reviews that show up in week one.
In-app purchases add a second review track
Any subscription or in-app purchase flow gets reviewed against pricing display rules, restore-purchase requirements, and a policy on external payment links that both platforms enforce more strictly than most first-time submitters expect. Budget it as its own review pass, not an afterthought bundled into the main submission.
Privacy labels are checked against what the app does, not what you say
Apple's privacy nutrition label and Google's data safety section both ask you to declare exactly what the app collects and why, and reviewers spot-check those declarations against the actual network traffic the build generates. A third-party analytics SDK you forgot was collecting device identifiers is the kind of mismatch that gets a build rejected on the second look, not the first.
What ships after v1
Shipping v1 is roughly half the lifetime cost
The build is the part everyone quotes. The two years of OS releases after it are the part that decides whether the app is still working, and it is where most agencies stop talking, because it does not fit neatly into a fixed-price pitch.
OS version churn is a recurring bill, not a one-time risk
Apple ships a major iOS version every September and Google ships Android on a similar yearly cadence, and both deprecate APIs on a schedule you do not control. An app that stops targeting a current SDK version within roughly a year gets flagged, then delisted — maintenance is not optional here, it is a subscription.
Android fragmentation is still real
Dozens of manufacturers ship their own modifications to stock Android, with different defaults for battery optimization, notification permissions, and background restrictions. An app tested on a Pixel can behave differently on a Samsung device with aggressive battery management switched on by default.
Battery and performance are the reviews you actually get
Users rarely leave a review about a missing feature. They leave one when the app drains the battery or a screen stutters. Profiling battery draw and frame rate on mid-range devices, not just the newest phone on your desk, is what keeps that review from happening.
A device lab matters more than a bigger simulator fleet
A simulator catches layout bugs; it does not catch the thermal throttling, the real GPS drift, or the background app-refresh behavior that only shows up on physical hardware a couple of OS versions behind current. A short list of real devices covering both platforms and at least one mid-range Android phone belongs in the test plan, not just the CI pipeline.
How an engagement runs
From framework decision to a build in both stores
The framework decision happens before anything is estimated, because it changes both the cost and the timeline above. After that, delivery follows the same two-week cadence as any other build here: a working app on a device you can hold, every increment, rather than a status update describing one — and the app you hold in week four is on the same architecture that ships to the store, not a throwaway prototype rebuilt later.
Related
Related services
What mobile projects usually need alongside the app itself.
Questions
Questions
What teams ask before a first call.
A single-platform MVP is the smallest of these, a cross-platform React Native build covering both stores sits in the middle, and a fully native iOS and Android build is the largest. None of them assume you already have designs, since design is usually the missing piece when someone asks.
Integration count and whether the app works offline are what move a mobile quote most. A scoping call produces a figure faster than any range on a page would.
Native when the platform's own capability — camera, ARKit, background location, this year's widget API — is the product rather than a feature. React Native when your team already knows React and the interface matters more than squeezing the last frame out of the GPU. Flutter when the UI is unusually custom and needs to render identically on both platforms, and you are prepared to hire for Dart, or to accept a smaller pool of candidates who already know it.
None of these is more sophisticated than the others. The wrong one for your team and your roadmap is the expensive choice, regardless of which one is fashionable this year, and switching frameworks after launch is a rebuild, not a refactor.
If the product's job is to display information, take a form, or let someone browse a catalog, a responsive site or a progressive web app does it without app store review, without two codebases, and without asking anyone to download something. It updates the moment you deploy, and it reaches search traffic an app store listing never will.
An app earns its cost when you need the camera, offline access, push notifications a user actually wants, or a home-screen icon that drives daily return visits. Building an app because a website feels less impressive is the most common overspend we see in this category, and it is the one we will talk you out of first if the workflow does not need it.
Apple typically clears a submission in 24 to 48 hours, but a rejection resets the clock, and reasons range from a broken flow to subscription-language guidelines unrelated to your code. Google's Play Store review is usually faster but checks data safety declarations literally, and a mismatch there can pull a build after launch rather than before it. Both stores also review every update, not just the first submission, so this risk does not go away after v1.
Treat review as a real step with real risk, not a formality after the build is done. A buffer week before any date promised to a stakeholder is not padding, it is the honest schedule, and it is cheaper than moving a public launch date after a rejection.
Budget a monthly allowance for ongoing OS upgrades, deprecated API replacement, crash monitoring, and the SDK version bumps both app stores eventually require whether you want them or not. Shipping v1 is roughly half the lifetime cost of the app; the other half is keeping it working through two OS release cycles a year, plus the device models that ship in between.
Skipping this budget does not remove the cost, it just moves it to the week the app gets flagged for targeting an outdated SDK version, at which point it is a fire rather than a line item, and the fix competes for time with whatever else your team was doing that week.
Yes. Source code, backend infrastructure, and the App Store Connect and Google Play Console accounts should be registered under your own organization from day one, not ours, with us added as a developer. That is the arrangement we use, and it is the only one that does not lock you to a vendor to publish your own updates, submit a bug fix, or move to a different team later.
If an agency proposes building under their own developer account 'for now,' that is a switching cost being deferred, not avoided, and it usually surfaces the day you try to leave.