Apps get quoted as though shipping the code is the end of the work. Then the first App Store submission comes back rejected over a login requirement, a privacy label or a permission the reviewer did not think was justified, and two weeks disappear into a queue nobody scheduled.
After launch the problem changes shape. A web bug is fixed in an hour. An app bug is fixed in an hour, then waits for review, then waits for users to update. Some never update, so your backend has to keep supporting a version from last year.
Device range is the third cost. It works on the two recent phones the team owns and fails on a three-year-old Android with less memory, a smaller screen and a manufacturer's own battery rules that kill background work.
And a large share of app budgets goes on things that were never in the brief: push infrastructure, deep links, offline behaviour, forced-update handling, and store screenshots in every size two platforms between them demand.
Sound familiar?
A rejected submission and nobody who has read the review guidelines.
No plan for the users who never update the app.
Tested on two recent phones, shipped to thousands of older ones.
Crashes reported by customers rather than by monitoring.
Developer accounts registered to someone who has left.
A web release process applied to something that cannot be hotfixed.
React Native or Flutter when the app is mostly screens and data. Native Swift or Kotlin when it leans on hardware or needs frame-perfect performance. We tell you which and why before quoting.
App Store Connect and Play Console setup, privacy labels, data safety forms, screenshots at every required size, listing copy and responses to the reviewer, prepared and submitted from your accounts.
Staged rollout, a forced-update path for breaking changes, and an API versioning plan so older app versions keep working until people move off them.
What the app does on a train. Caching, queued actions and a sync strategy decided during design, rather than patched in after the first complaint.
Configured on both platforms, including when the permission prompt appears, which is what actually determines whether anyone opts in.
Sentry or Firebase wired in from the first build, so you find out about a crash from a dashboard rather than from a one-star review.
App projects are paced by review queues rather than by development speed, so the plan is built around submission dates instead of forwards from the kickoff.
Native or cross-platform, minimum OS versions, and the device range to support. This decision moves cost more than the feature list does.
Output: a written technical approach.
Internal builds distributed through TestFlight and Play internal testing from early in the project, so the app is on your own phone throughout rather than only at the end.
Output: an installable build you can use as it develops.
Real devices across the age and size range, while store assets, privacy declarations and listing copy are prepared in parallel.
Output: a submission-ready build and listing.
Submission, reviewer responses, staged rollout, then crash monitoring and a first-month fix cycle while real usage arrives.
Output: live apps and a monitoring dashboard.
The platform decision is the expensive one. Everything below follows from it.
React Native
Most business apps. One codebase, a near-native feel, and a large hiring pool if you later bring maintenance in-house.
Flutter
Where the interface is heavily custom or animation-led. Rendering is consistent across devices; the hiring pool is smaller.
Swift and Kotlin
Native, for apps that depend on hardware, background processing or platform features that cross-platform wrappers handle badly.
Firebase
Push, analytics, crash reporting and remote config in one place. Quick to set up and usually sufficient for the first year.
Sentry
Crash reporting with the stack trace and the steps that led to it, which is the difference between fixing a crash and guessing at it.
Fastlane
Automated builds, signing and store uploads. Removes the manual release ritual that goes wrong at the least convenient moment.
Not fixed to these
This is what we reach for by default, not a limit. Apps often have to fit an existing backend, an SDK your client requires, or a framework your in-house team already maintains, and we build in those. Tell us the constraints during scoping and we will say whether they change the approach or only the tooling.
Scope is driven by the platform decision and the number of distinct screens, not by a feature list. Two features sharing a screen are usually cheaper than one feature spread across four.
| Engagement | Typical timeline | Best for |
|---|---|---|
| Technical scoping and store audit | 1 – 2 weeks | Deciding platform and scope before committing |
| MVP, single platform | 8 – 14 weeks | Testing an idea with real users |
| Cross-platform app, both stores | 12 – 20 weeks | Accounts, payments, notifications, a real product |
| Native app | 16 weeks + | Hardware, background processing or performance-critical |
| Support and release retainer | Ongoing | OS updates, store policy changes, monitoring |
Timelines include preparing and making the submission but not the review itself, which takes one to seven days per attempt and is outside anyone's control. Backend work is quoted separately unless the app uses one you already run.
Every project is priced in writing after a scoping call. You get a fixed number, with what is included and what is not, so there is nothing to negotiate later.
Tell us what you need built and we will send a scope and a price. The reply comes from the person who would run the project.
Get a quote →This page describes how we prefer to work, not a fixed contract. Deliverables, stages and timelines vary with the size and shape of the project, and some of what is described here will not apply to yours. The written scope you receive after the scoping call is the version that counts. How we engage →
Cross-platform for most business apps: one codebase, one team, and roughly two thirds of the cost. Native when the app depends on the camera, Bluetooth, background location, heavy processing, or platform interface conventions that matter to your users. We make the call during scoping and show you the trade-off rather than defaulting to whichever we prefer.
We recommend registering the Apple Developer and Google Play accounts to your company, with us added as team members. Where that is not practical we agree the arrangement in writing before submission. Accounts registered to an agency are the most common reason companies lose control of their own app, and it is avoidable at setup.
We respond to the reviewer and resubmit. Most rejections are procedural: a missing privacy declaration, an unclear permission justification, no demo account supplied. We build submissions against the guidelines so rejections are uncommon, but the schedule assumes one round anyway.
A commercial decision rather than a technical one. We look at your website analytics, or at market data for your regions, and show you what each additional year of Android support costs in testing versus what share of users it reaches. Then you choose.
Only if you do not already have one. If you have an API we build against it, and will flag where it needs changes for mobile, usually around pagination, payload size and token handling. If there is nothing there, the backend is a separate scope.
Apple charges 99 US dollars a year, Google 25 US dollars once. Beyond that, budget for two or three releases a year even with no new features: operating system updates break things, store policies change, and libraries need patching. A retainer covers that work.
Every enquiry gets a reply within one working day, from the person who would run your project.