The hard part of an app is not shipping it. It is that the average app loses most of its users in the first week, and almost nobody plans for that before launch. We build with retention instrumented from the first release, because a download nobody returns to is a cost, not a result.
Mobile app development covers design, engineering, store submission and post-launch iteration for iOS and Android. React Native suits most business apps and takes three to six months. An MVP typically reaches both stores in three to four months and a full product in five to eight.
You are using a real installable build before the halfway point, not reviewing screens in a deck.
React Native where it fits — one team, one codebase, iOS and Android released together.
Apple and Google developer accounts registered to your company, not to the agency.
Crash triage and store review responses in the window where they matter most.
Product definition and scope
Tested prototype
TestFlight and Play internal builds
Beta report and fix list
Live on both stores
Monthly release and metrics review
The app shipped on time. The team celebrated. Six weeks later daily active users are a rounding error, and there is no instrumentation to explain why — because analytics were 'phase two' and phase two never got funded.
Often it does not, and we say so. Here is when it genuinely does, by the kind of business asking.
Staff reporting by WhatsApp from places with no signal, with photos and forms transcribed by someone in the office.
An offline-first app that captures work where it happens, queues it, and syncs when there is signal.
Repeat customers re-acquired through paid ads every time, because there is no owned channel to reach them.
An app with saved carts, order tracking and push for restock and reorder moments.
Adherence and follow-up depend on the patient remembering, so outcomes and revisit rates suffer.
Reminders, progress tracking, report access and a booking flow in the patient's pocket.
Course content in a browser that students on limited data plans cannot use on the commute.
Downloadable lessons, offline progress, streaks and notifications tuned to actual study behaviour.
Onboarding that requires a desktop and a scanner, so applications are abandoned mid-way.
Camera-based KYC, autofill, saved progress and a status view that stops the support calls.
Engagement scattered across WhatsApp groups nobody can moderate or measure.
A structured space with profiles, notifications and content the organisation controls.
Not the framework. Not the design. These four, consistently, in every post-mortem we have ever run on a struggling app.
Every screen between opening the app and the user getting something useful costs you a share of installs. Signup walls before value are the most expensive default decision in mobile.
Activation, retention and the funnel through onboarding, tracked from day one. Without it, every roadmap conversation after launch is opinion.
Test on a mid-range Android on a throttled connection, because that is your user. An app that only feels good on the developer's iPhone will be judged on the store by people using something else.
Apps that ship every few weeks recover from a bad launch. Apps that ship once do not. Budget for the year, not for the launch.
The one job the app does that the mobile web cannot, written down. If we cannot answer that honestly, we will recommend a responsive site instead.
Native-feeling flows in Figma, tested on a phone in someone's hand before engineering starts.
React Native for most business apps; native Swift or Kotlin where the app leans on hardware, background processing or platform-specific behaviour.
The services behind the app, versioned so an old app version on someone's phone does not break — see [API Development & Integrations](/services/api-development-integrations).
Local storage, queued actions and conflict handling, so the app works in a basement, a lift and a village.
Notification strategy built around genuine moments, with permission requested when it makes sense rather than on first launch.
Activation funnel, retention cohorts and crash triage wired in before submission, not after.
Listing copy, screenshots, review guidelines compliance, staged rollout, and handling the rejection that happens to everyone at least once.
Every tool on this list is one we have shipped and still maintain for a paying client. Nothing here is aspirational — if it is not in production somewhere, it is not on the page.
Chosen on what the app has to do with the device, not on preference.
One codebase for iOS and Android. The right answer for most business apps — forms, lists, media, payments, notifications.
Over-the-air updates and a far simpler build pipeline, which for a small team is the difference between shipping fortnightly and quarterly.
Where the app leans on hardware, background processing or platform features that a bridge makes awkward.
Same reasoning on the Android side, plus the cases where the Android install base demands very low-end support.
Where a client's existing team already works in it. We will maintain it; we rarely propose it for a new build.
The parts that decide whether the app is fast, reliable and measurable.
Versioned endpoints so an old app version in someone's pocket keeps working after a release.
The system of record behind the app, shared with the web product where there is one.
Push notifications, crash reporting and realtime sync, which is genuinely hard to beat for the price.
Activation funnel and retention cohorts from release one, joined with acquisition data.
The hard part of an app is not shipping it. It is that most installs stop being used within a week, and almost nobody plans for that before launch.
An app earns its cost when you need offline capability, hardware access, push as a genuine channel, or high-frequency use. If the job can be done in a browser and people visit occasionally, a fast responsive site is cheaper to build, easier to change and far easier to find. We turn down app projects on this basis regularly.
React Native for most business apps — forms, lists, media, payments, notifications. One codebase, one team, both platforms, and a release cadence a small company can actually sustain. Expect around a third off building twice, not half; ten to twenty percent of the code stays platform-specific and a plan that assumes otherwise will be wrong by exactly that much.
Native Swift or Kotlin when the app leans on hardware, background processing or platform-specific interaction where a bridge makes things fragile. The full comparison is in React Native development in India.
Installs can be bought. A user who comes back on day thirty cannot. Before spending anything on paid installs, get day-one and day-seven retention to a healthy place — otherwise the budget converts into uninstalls and teaches the ad platform to find you more of the same people. The benchmarks and the fixes are in app retention and onboarding.
The back-end services, versioned so an old app version on someone's phone keeps working after a release; offline handling where the app is used in places with poor signal; and a notification strategy built around genuine moments rather than announcements. The API layer is covered on API Development & Integrations.
Every stage ends in something you can hold — a document, a build, a live account. If a stage cannot name its output, it is a meeting, not a stage.
What the app does that a website cannot, who it is for, and what the first release contains.
Flows and screens, tested on a real device with real people before code.
An installable build on your phone from week six, updated fortnightly.
Twenty to a hundred users, instrumented, with crash reporting and a weekly triage.
Listings, screenshots, privacy declarations and staged rollout — plus the resubmission if review rejects it.
Retention cohorts reviewed monthly and a release cadence that continues past launch.
Everything here is part of the engagement at no extra cost. We do not itemise them on an invoice and we do not withhold them if you leave.
Often the answer is a fast responsive site instead, and we will say so before quoting. That conversation costs nothing.
Activation funnel, retention cohorts and crash alerting wired in before submission rather than added after the first bad review.
Listings, screenshots, privacy declarations and the resubmission that happens to almost everyone at least once.
Low, mid and high-end Android plus iOS — because your users are not all holding the newest phone.
Apple and Google developer accounts registered to you, with us added as developers. Agency-owned store accounts are painful to unwind and we do not create that situation.
Longer answers to the questions people ask before they hire anyone for mobile apps.
Built by us, free, no signup, nothing uploaded to a server. Take them whether or not you ever become a client.
It is scoped on the number of workflows, whether it needs offline behaviour and payments, and how many systems it integrates with — not on screen count, which is the number most quotes are built from and the least predictive. We have broken the cost drivers down in [what a mobile app costs in India](/blog/mobile-app-development-cost-india).
Tell us what you have now and what you are trying to reach. We will audit it and tell you what we would do, what it would cost and whether you need us at all. The audit is free and yours to keep.