How we work
Our Mobile App Development Process, Step by Step
This is our mobile app development process as it actually runs, from the first workshop to the release after launch. You will see what happens in each phase, what you receive at the end of it, how we communicate across time zones and how changes are handled without blowing up the budget.
- NDA before discovery
- Code in your repository from day one
- Installable demo build every sprint
The six phases of our mobile app development process
Every phase ends with something you can review, sign off or install. Nothing important lives only in a call.
Discovery (1 to 2 weeks)
Workshops with you and, ideally, a few target users. We map user flows, list every screen and integration, and agree what is in version one. You receive a written scope document (see our app requirements document template), a prioritised backlog with acceptance criteria, an architecture recommendation and a fixed estimate. The scope document is yours to keep, even if you build elsewhere.
UX/UI design
Low-fidelity wireframes first, so we argue about structure before colours. Then a clickable Figma prototype you can tap through on your phone and show to users. Design is signed off screen by screen before development of that area starts. More on our mobile app UI/UX design service.
Development in two-week sprints
Each sprint starts with a planning call and ends with a demo. Every sprint you get an installable build through TestFlight for iOS and Google Play Console internal testing for Android. Code goes into your own GitHub, GitLab or Bitbucket repository from the first commit, with pull requests reviewed by a second engineer.
Quality assurance
QA runs inside every sprint, not at the end. We test on real iPhones and Android devices across screen sizes and OS versions, run automated unit and UI tests in CI (GitHub Actions or Codemagic), and wire up Crashlytics or Sentry from the first beta so crashes are visible before users report them.
Launch
We prepare store listings, screenshots and privacy details, then handle App Store and Google Play submission from your accounts. We check against the guidelines that cause most rejections: 2.1 App Completeness, 4.2 Minimum Functionality and 5.1.1 Data Collection and Storage. Release is staged where possible.
Support and growth
After launch we monitor crashes and reviews, fix defects, keep up with platform deadlines and plan the next release from real usage data. Support can be a monthly app maintenance and support retainer or a continuing dedicated team.
Why discovery comes before a fixed price
The most common reason an app project slips is not slow developers. It is a scope that sounded clear in a meeting and turned out to hide a second user role, an offline mode or an integration nobody had tested. Discovery is where we find those before they cost sprints. For typical timelines by app size, see how long does it take to build an app?
It is also where the fixed price comes from. We estimate the backlog line by line in hours, so you can see why the number is what it is and which features carry the most weight. If you want to sense-check the budget first, try the app cost calculator, and for the logic behind it read our app development cost guide.
Communication cadence
You always know what happened yesterday, what is happening this week and what you will see at the end of the sprint.
| When | What | Who | Channel |
|---|---|---|---|
| Daily | Written update: done, next, blockers, questions for you | Project manager | Slack or Microsoft Teams |
| Daily (optional) | 15-minute stand-up inside the overlap window | PM, tech lead, your product owner | Google Meet or Zoom |
| Weekly | Progress call: burn-down, risks, decisions needed | PM and your product owner | Video call |
| Every sprint (2 weeks) | Sprint demo with installable build and release notes | Whole team and your stakeholders | Video call plus TestFlight and Play internal testing |
| Every sprint | Planning for the next sprint and backlog review | PM, tech lead, your product owner | Jira or Linear |
| Monthly | Budget and timeline review against plan | PM and your budget owner | Written report plus call |
You get one named project manager as your main contact throughout. The daily stand-up sits inside your overlap window; hours by region are on our contact page, and US teams can read our guide on Pakistan developers and the US time zone.
Tools we use
We work in your tools if you have them. If not, our defaults are Figma for design, Xcode, Android Studio, Flutter or React Native for the build, GitHub Actions, Fastlane or Codemagic for CI/CD, TestFlight and Play Console internal testing for beta builds, Crashlytics or Sentry for monitoring, and Jira or Linear for the backlog. Why we pick each stack for a given app is on our mobile app development technologies page.
See how this would run for your app
In a 30-minute call we walk through your idea, suggest the right engagement model and outline what discovery would cover.
What we need from you
Projects run fastest when these are in place before the first sprint.
- One product owner who can make decisions and answer questions within a working day
- Access to your Apple Developer and Google Play Console accounts (or help to create them in your name)
- A code repository in your organisation, with contributor access for our team
- Brand assets: logo, colours, fonts and any existing guidelines
- Credentials and documentation for third-party services you already use
- Time for sprint demos, ideally with someone who represents your users
- Written feedback on each demo build within the agreed review window
How change requests work
Anything outside the agreed scope is written up by the project manager with an hour estimate and its effect on the timeline, and nothing is built until you approve it in writing. How that works under each contract type, including scope swaps on fixed price, is set out on our app development engagement models page.
Quality gates: our definition of done
A story is not done until it passes every gate below. This is how the build you install each sprint stays releasable.
- Meets every acceptance criterion written on the ticket
- Code reviewed and approved by a second engineer through a pull request
- Unit tests written for business logic; CI pipeline passes
- Tested on real iOS and Android devices at small and large screen sizes
- No new crashes or errors in Crashlytics or Sentry from the test build
- Accessibility basics checked: text scaling, contrast, screen-reader labels
- Matches the signed-off Figma design, or the difference is agreed in writing
- Account deletion available in-app wherever users can create an account, as Apple requires
- Release notes updated and build uploaded to TestFlight and Play internal testing
Keeping your app compliant after launch
Apple and Google change the rules every year, and an app that is not maintained eventually cannot ship updates. Apple now requires App Store uploads to be built with Xcode 26 or later using the iOS 26 SDK, and Google Play requires new apps and updates to target Android 16 (API level 36) from August 31, 2026. Apple also requires in-app account deletion for any app that lets users sign up. Our support plans include tracking these deadlines and scheduling the work well before they bite.
For a broader explainer of each stage, read the mobile app development process: 7 stages explained.
Questions about our process
How long does the mobile app development process take?
Discovery takes one to two weeks. Design and development then run in two-week sprints, and a focused MVP often needs around 8 to 16 weeks after discovery. Larger, multi-role products are planned as phased releases over several months. The schedule depends mostly on scope and on how quickly decisions are made on your side.
Can I see progress during development?
Yes. Every two-week sprint ends with a demo and an installable build through TestFlight on iOS and Google Play internal testing on Android, so you test on your own phone. You also get a daily written update and access to the backlog in Jira or Linear. The code sits in your repository, so you can inspect it at any time.
Do I need a technical person on my side?
No, but you do need a product owner who can make decisions. We explain technical choices in plain terms and record them in writing. If you have a CTO or tech lead, we involve them in architecture decisions and code reviews. If you do not, our tech lead covers that role and documents choices so another team could pick them up later.
What happens if I want to change something mid-project?
Each change is written up with an hour estimate and timeline impact, and nothing is built until you approve it in writing. How that plays out under fixed price, time and material and dedicated team contracts is set out on our app development engagement models page.
Who submits the app to the App Store and Google Play?
We do, from accounts registered in your name. We prepare listings, screenshots and privacy details, check the build against common rejection reasons such as App Completeness and Minimum Functionality, and handle any reviewer questions. If Apple or Google rejects the build, we fix the issue and resubmit as part of the launch work.
What does support look like after launch?
We monitor crashes and store reviews, fix defects, update the app for new OS versions and platform rules, and plan new features from usage data. Support can be a monthly retainer with agreed response times or a continuing dedicated team. Either way, the code and accounts stay yours, so you are free to move on.
Start with a 30-minute scoping call
Tell us what you want to build. We will explain how discovery would work for your app, who would be on the team and what you would see at the end of the first sprint.