How long does it take to build an app, realistically
Three to four months for a focused first version, six to nine for something substantial. The variance is almost never engineering speed; it is decisions and integrations.
Key takeaways
- Three to four months for a focused first version; six to nine for accounts, payments and integrations.
- Waiting for decisions is the largest cause of overrun; name one person with authority to answer.
- Start payment gateway approvals in week one, since approval often takes longer than implementation.
- Ask a supplier what would make the project take twice as long; a specific answer indicates a real estimate.
A focused first version of a cross-platform app typically takes three to four months from start to store. Something substantial, with accounts, payments and back-office integration, runs six to nine. The difference between a project that hits those and one that doubles them is rarely how fast people write code. It is how quickly decisions get made and how well the integrations were understood beforehand.
- 3–4 months
- focused first version, cross-platform, limited integrations
- 6–9 months
- substantial app with accounts, payments and back-office integration
- 2–4 weeks
- typical additional time for bilingual Arabic and English delivery done properly
A realistic shape for four months
- Weeks one to three: discovery, specification, interface design of the core flows, and confirming every integration is actually available.
- Weeks four to twelve: build, with something demonstrable every fortnight. If there is nothing to look at by week six, the project is already in difficulty.
- Weeks thirteen to fifteen: quality assurance on real devices, both platforms, both languages, poor networks, and fixing what that finds.
- Weeks fifteen to sixteen: store submission, review, and the resubmission you should assume will be needed.
What actually causes overruns
Waiting for decisions is the largest single cause. A question that sits unanswered for a week costs a week, and these accumulate invisibly because no individual delay looks serious. Assign one person with authority to answer, and agree that unanswered questions are resolved by the team's best judgement after a fixed period rather than blocking.
Integrations are the second. Payment gateway approval in particular can take longer than the implementation, and regional gateways vary considerably in how long onboarding takes. Start every approval process in week one, before anything is built, so the waiting overlaps with the work rather than following it.
What does not speed it up
Adding engineers to a late project, which slows it further while they are brought up to speed. Skipping quality assurance, which converts a schedule problem into a reputation problem. And working in parallel on features that depend on an unresolved decision, which produces code that is thrown away.
The honest question to ask a supplier
Not how long will it take, which invites an optimistic number, but what would have to be true for this to take twice as long. A supplier who answers that specifically, naming the integrations they have not yet verified and the decisions they need, is estimating. One who cannot is guessing.
Ask what would make this take twice as long. The quality of that answer tells you whether the estimate is real.