You have signed with a development team, paid the advance, and now you are waiting. Weeks pass. You get occasional screenshots. You are not sure whether things are on track or quietly going wrong, and you do not know enough to ask the right questions.
That uncertainty is avoidable. The mobile app development process follows a fairly predictable shape, and once you know what each stage produces and what it costs you to get it wrong, you can tell a healthy project from a troubled one. This walks through every stage from the client's side — what happens, how long it takes, what you should be receiving, and where projects usually derail.
Stage 1: Discovery and scoping
Duration: 1–3 weeks. Typical share of budget: 5–10%.
Discovery converts "I want an app for X" into a document a developer could build from without asking you anything. It is the stage clients most want to skip and the one whose absence causes the most expensive problems later.
What actually happens
Someone sits with you and works through: who uses this app, what are they trying to accomplish, what is the single most important action, what happens when things go wrong, what systems does this need to talk to, and what does success look like in six months. Then they write down every screen and every rule.
What you should receive
- A feature list, split into must-have for v1 and later
- A user flow or screen map showing how someone moves through the app
- A written list of business rules — who can do what, what the states are, what triggers a notification
- Technical decisions: framework, backend, hosting, third-party services
- A revised estimate and timeline based on the above, not on the initial conversation
Where it goes wrong
The estimate came from a 45-minute call and nobody wrote down the rules. Three months later there is a disagreement about whether "cancel order" was supposed to trigger an automatic refund, and both sides genuinely believe they were clear. Insist on a written scope before development starts, even if it costs ₹40,000–₹1,00,000. It is the cheapest insurance in the whole project.
Stage 2: UI/UX design
Duration: 2–5 weeks. Typical share of budget: 15–20%.
Design is not decoration. It is where you decide how the app works, in a medium that is cheap to change. Moving a button in Figma takes a minute; moving it after it is coded, tested, and integrated takes a day.
Wireframes first
Grey boxes, no colour, no branding. This forces conversations about structure rather than aesthetics. Review these carefully. If you approve wireframes where the main action is three taps deep, no amount of visual polish later will fix it.
Then visual design and a design system
Colours, typography, spacing, iconography, and a set of reusable components. The design system matters more than the individual screens: it is why screen 34 does not need to be designed from scratch, and it is what keeps the app consistent as it grows.
Then a clickable prototype
A linked set of screens you can tap through on your own phone. Do this. Ten minutes with a prototype surfaces problems that a hundred static screenshots hide.
Where it goes wrong
Two failure modes. First, designing only the happy path — no empty states, no loading states, no error messages, no "what does this look like when the user has zero orders". Developers then invent these under time pressure and the result is inconsistent. Second, endless revision cycles. Agree upfront on how many rounds are included, usually two or three, and be decisive.
Stage 3: Technical architecture and planning
Duration: 1–2 weeks, often overlapping with design.
This is mostly invisible to you, which is why it gets skipped. The team decides the database structure, the API contract between app and server, how authentication works, where files are stored, and how the app behaves offline.
Why you should care
Architecture decisions are the hardest to reverse. Choosing the wrong database structure for how your data actually relates is a rewrite six months later, not a fix. A team that starts coding screens in week one without an agreed data model is a warning sign.
What to ask for
- A database schema or entity diagram, even a rough one
- The API endpoint list — this doubles as a progress tracker later
- Where user data lives, and whether that raises any compliance concerns for your business
- What the app does with no internet connection
Stage 4: Backend development
Duration: runs alongside app development, typically 4–12 weeks.
The backend is the server, database, business logic, and admin panel. Clients underestimate it constantly because it is invisible — there is no screenshot to show. But for most apps, the backend and admin panel are 40–50% of the total effort.
The admin panel deserves attention
This is the tool your team will use every single day to add products, view orders, handle refunds, and answer customer questions. It is routinely built last, quickly, and badly. Ask to see it while it is being built, not after launch. A frustrating admin panel costs you staff hours forever.
Integrations happen here
Razorpay or your chosen gateway, SMS and OTP with DLT registration, push notifications, maps, email, any ERP or CRM. Each integration has its own approval process and its own surprises — DLT template approval for SMS in India can take days on its own and is a classic timeline surprise. Get these started early, not in the final sprint.
Stage 5: App development
Duration: 6–20 weeks depending on complexity.
Screens get built, connected to the API, and made to work. This is the longest stage and the one where communication discipline matters most.
How progress should be visible
You should get a working build you can install on your own phone every one to two weeks. Not screenshots. Not a video. An installable build. This is the single most useful thing you can insist on, because it makes progress impossible to fake and lets you catch misunderstandings while they are cheap.
Use a distribution service (Firebase App Distribution, TestFlight, or a direct APK) and actually install it. Try to break it. Report what feels wrong, not just what is broken.
Feature order matters
Ask for the riskiest and most core feature first, not the login screen. If your app is about live tracking, build live tracking in week two. Teams naturally build easy things first because it produces visible progress, and that hides risk until late.
Where it goes wrong
Two things. Scope creep: you see the app, get ideas, and each small addition is agreed informally. Twelve small additions later the timeline has slipped by a month and nobody can point to the decision that caused it. Keep a written change log with cost and time impact per change, even for small ones.
The other is silence. If two weeks pass with no build and vague status updates, escalate immediately. Problems in software do not resolve themselves quietly.
Stage 6: Testing and quality assurance
Duration: 2–5 weeks, partly overlapping with development. Typical share of budget: 10–15%.
Testing is not "clicking around to see if it works". Structured QA covers a lot of ground clients do not think about.
What good testing covers
- Functional: every flow, every rule, including the ones nobody wants to think about — what happens if payment succeeds but the app closes before confirmation
- Device coverage: in India this means testing on genuinely cheap Android phones with 3–4 GB RAM, not just a flagship. Different OEM skins behave differently; Xiaomi and Vivo devices in particular kill background processes aggressively, which breaks notifications and sync in ways that never appear on a Pixel.
- Network conditions: throttled 3G, connection dropping mid-request, switching between wifi and mobile data during an upload
- Edge data: very long names, emoji, zero results, ten thousand results, expired sessions
- Security basics: can a logged-out user hit an API endpoint directly, are tokens handled properly, is anything sensitive stored in plain text
Your role: user acceptance testing
You and a handful of real users should run through actual scenarios end to end before launch. Not a demo — genuine use. Place a real order. Request a real refund. This is where you find that a rule everyone assumed was obvious was implemented backwards.
Stage 7: Deployment and store submission
Duration: 1–3 weeks, mostly waiting.
Getting into the stores is a process with its own rules and its own delays.
What is involved
- Play Store and App Store developer accounts — registered in your company's name, not the agency's. Do not compromise on this.
- Store listing: title, description, keywords, screenshots, feature graphic. This is app store SEO and it deserves real effort, not a rushed hour.
- A privacy policy URL and data safety declarations. Both stores require accurate disclosure of what data you collect.
- Production backend deployment, with monitoring, backups, and error tracking configured before real users arrive.
Expect rejection at least once
Apple's review is stricter and rejections are routine — incomplete metadata, login required with no test credentials provided, unclear data usage, or a feature the reviewer could not reach. Build a week of buffer for this into your launch plan rather than promising a date you cannot control.
Stage 8: Post-launch
The project does not end at launch; the useful part begins there.
The first two weeks
Expect a burst of crashes and bugs that never appeared in testing, because real users do things testers do not. Have crash reporting in place from day one, and have an agreement about who fixes what and at what cost. A typical arrangement is 30–90 days of free bug fixing for defects, with new features quoted separately.
Ongoing maintenance
Budget 15–20% of build cost annually. This is not optional. Android and iOS ship breaking changes yearly, payment gateways deprecate API versions, libraries stop being maintained, and an app left untouched for two years often will not build at all, let alone run.
Handover
Before final payment, confirm you have: source code in a repository you own, all account credentials, deployment documentation, design source files, and a working environment setup guide. Verify this by having someone else attempt to build the app from the repository. Many clients discover the gap months later, at the worst possible time.
A realistic timeline
| Stage | Simple app | Mid-complexity | Complex / marketplace |
|---|---|---|---|
| Discovery | 1 week | 2 weeks | 3–4 weeks |
| Design | 2 weeks | 3–4 weeks | 6–8 weeks |
| Development | 4–6 weeks | 10–14 weeks | 20–36 weeks |
| Testing | 1–2 weeks | 3 weeks | 5–8 weeks |
| Launch | 1 week | 1–2 weeks | 2–3 weeks |
| Total | 2–3 months | 4–6 months | 9–15 months |
Stages overlap in practice — backend and app development run in parallel, testing starts before development finishes — so the total is less than the sum.
The four things that keep a project healthy
- Install a build every two weeks. The single highest-value habit. It makes progress real and catches misunderstandings early.
- Write down every change. Including the small ones, with cost and time impact. Verbal agreements become disputes.
- Front-load the risky work. The hardest feature first, integrations started early. Easy things are easy whenever you do them.
- Own your accounts. Stores, cloud, domain, repository, all in your name from day one.
The recommendation
Do not skip discovery and do not skip design, even when the budget is tight and the temptation is strong. Together they are around a quarter of the cost and they prevent nearly all of the expensive rework. A project that starts coding in week one with no written scope will cost more and take longer than one that spent three weeks getting clear first — not sometimes, reliably.
Then insist on an installable build every fortnight, keep a written change log, and get the riskiest feature built first. Those four habits will do more for your outcome than choosing a different agency, a different framework, or a bigger budget. The mobile app development process is not complicated to follow. It is just easy to shortcut, and the shortcuts are what cost money.