The time a business app takes depends less on screens than on decisions. Which systems it connects to, whether it works offline, how many device types it supports and how quickly your team approves each step all move the date. This guide lists the phases, the choices that add weeks, and the store rules to plan around.
Last reviewed 8 November 2026 against the sources listed at the end. This guide gives no fixed number of weeks, because the number comes from your answers to the questions below. Ask any vendor to show how its figure follows from them.
The phases, and what sets each one's length
| Phase | What happens | What decides how long it takes |
|---|---|---|
| Discovery | Watch the work, list the users, fix the scope | Number of user roles; how many people can give time each week |
| Design | Flows, screens, a clickable prototype tested with real users | Number of screens and roles; how quickly you approve |
| Build | Fortnightly releases of working software | Integrations, offline needs, platforms |
| Test and harden | Device testing, security review, performance, fixes | Device range; sensitivity of the data |
| Store release | Accounts, listing, review, staged rollout | Account set-up, store review, privacy forms |
| Rollout | Training, device set-up, support | Number of sites and users; whether the app is internal |
Build is the longest phase on most plans. Watch integrations and approvals inside it. The sections below list the causes.
Eight decisions that add weeks
Decisions about the build
1. Connections to your existing systems. An app that stands alone is quick. An app that reads and writes your ERP, your attendance system or a legacy database is not. Each connection needs access, test data and a person who knows the old system. List every system the app touches before you ask for a date.
2. Offline use. Field staff in plants, mines, depots and villages lose signal. An offline-first app stores work on the device and syncs later. That means deciding what happens when two people edit the same record. It is the right design for field work, and it adds build and test time.
3. Platforms. One codebase for Android and iPhone (React Native or Flutter) is a common choice for business apps. Native code is warranted when the app needs specific hardware or a very particular interface. Two native apps need two sets of engineering and testing.
4. Roles and approvals inside the app. Each user role has its own screens, rules and tests. Each role adds its own work, and the way roles interact needs testing too.
Decisions about data, people and scope
5. Data quality at the start. If the app shows customer, item or asset lists, someone must clean them first. Duplicate and missing records appear on a phone screen immediately.
6. Login and permissions. Sign-in with your company directory, one-time passwords and device binding each add work. Decide the rule for a lost phone on day one.
7. Slow decisions. A design that waits two weeks for sign-off moves every date behind it. Name one product owner who can say yes. On Brihat projects that person gives a couple of hours a week during build.
8. Late scope. Each added feature after design resets part of testing. Keep a written list for the next release instead of folding it in.
A worked example, without the weeks
Take a field-service app for a manufacturer's engineers. It has three roles: engineer, supervisor and stores clerk. It reads work orders from the ERP, writes job notes back, and must work in a plant basement with no signal.
Count the inputs. Three roles, one system to connect, offline use, two platforms, several sites. Mark the unknowns. Does the ERP expose work orders through an interface, or does one need building first? Who cleans the asset list? Who signs off screens for each role?
The ERP interface is the first unknown to close, because everything else waits on it. Offline sync is the second, because it shapes the data design. Screens are the third, and they are the easiest to adjust later. A plan that sequences the work in that order, and names a person for each unknown, gives a date you can defend. A plan that starts with screens and discovers the ERP in month three does not.
Store rules to plan around
Stores add dates you do not control. Plan for them in the schedule rather than discovering them at launch.
- Apple review. Apple says App Review typically reviews at least 50 percent of submissions in under 24 hours and 90 percent in under 48 hours. The remainder take longer, and a rejection means another review. Leave room for one rejection.
- Google Play, new personal accounts. A personal developer account created after 13 November 2023 must run a closed test with at least 12 testers opted in continuously for 14 days before applying for production access. That is two weeks you cannot shorten. Check whether your company should publish from an organisation account instead; Google's page on this rule covers personal accounts only.
- Android target version. According to Google Play's target API level page, new apps and updates must target Android 16 (API level 36) or higher from 31 August 2026. Check the page for the current requirement before you start, because it changes each year.
- Privacy forms. Both stores ask you to declare what data the app collects. Settle that with your legal or security team while the app is built, not on release day.
An internal app for your own staff can skip the public stores. It can go out through device management, which is a separate set-up task.
The Indian data law belongs in the plan
If the app collects personal data, the Digital Personal Data Protection Act, 2023 and the DPDP Rules, 2025 apply. Per Rule 1 of the DPDP Rules, 2025, most duties apply 18 months after notification (13 November 2025). An app released after that point must meet them from its first day.
Three build items follow. A notice and a consent screen that name each purpose. A way for the user to withdraw consent that is as easy as giving it. A published contact for questions and grievances. If your users include children, parental consent must be verifiable. Our DPDP checklist for websites and forms lists each duty.
How to get a date you can trust
- Count your inputs. User roles, screens, systems to connect, platforms, sites. Write them down.
- Mark each as known or unknown. Unknowns are where dates slip. Turn them into discovery tasks.
- Ask for the plan by phase, with the dependency on your team stated for each.
- Look for a release every fortnight. A real build produces working software on a schedule, so you can test it. A schedule with no release until the end hides risk.
- Add the store dates from the section above, plus one rejection.
For a broader view of phases in a large system, see how long a custom ERP takes, phase by phase. For why scope and decisions sink projects before any code, see software projects fail in the two months before the code. To roll out in steps rather than at once, read big bang or phased.
Questions teams ask
Can a smaller first release come sooner?
Yes, when the scope is smaller in ways that matter: fewer user roles, one platform, no offline mode, one system to connect. Pick the cuts from the list of eight decisions above. Cutting screens alone saves little if the integration stays.
Does a cross-platform app take half as long as two native apps?
No fixed ratio applies. Shared code reduces engineering work, but design, testing on devices and store release still happen for each platform.
When should the store accounts be set up?
At the start. Account verification and the Google Play closed-test window run in parallel with the build only if they begin early.
Where Brihat fits
Brihat Infotech builds mobile applications for field teams and customers, offline-first where the work needs it. Start a conversation.