The number people quote, and the number that matters
Ask how long an app takes and you will hear a build estimate — the weeks a developer expects to spend
writing it. That number is usually honest and almost always incomplete.
The calendar between "we have agreed" and "it is on my phone from the store" includes design, review
cycles, testing on real devices, a backend that has to be deployed somewhere, store submission, and
the gaps where everyone waits for a decision. On most projects, coding is somewhere between a third
and a half of the elapsed time.
Here is where the rest of it goes.
Stage one: deciding what it is, one to three weeks
Not a formality, and not a phase you can skip by having a clear idea. A clear idea in one person's
head is not the same as a written scope three other people can build against.
This stage ends when there is a list of screens, a description of what each one does, and — the part
people resist — a written list of what is not in version one. Projects without that list do not run
late for any single dramatic reason. They run late because every week adds something small.
If the product is unclear rather than just unwritten, budget the upper end. A week spent arguing on a
whiteboard is much cheaper than the same argument happening later against working code.
Stage two: design, two to four weeks
Wireframes first, then the actual interface. The value here is not that the app looks better — though
it does. It is that every layout disagreement happens now, on a prototype, where a change costs
minutes.
This runs in parallel with backend setup, so it is not always four weeks of nobody coding.
The common way this stage slips: feedback arrives in fragments over ten days instead of in one round.
Two consolidated review rounds are faster than six scattered ones, and the difference is often a full
week.
Stage three: the build, four to twelve weeks
The number that gets quoted. Its width depends on the same drivers that move
the cost of the app — accounts, integrations, offline support,
number of user roles.
Two things reliably stretch it.
Integrations behave differently in production than in sandbox. A payment gateway that worked
perfectly in test mode starts returning a status nobody documented, and the fix is a support ticket
with someone else's turnaround time attached.
And content. The app is finished except that the T&C is not written, the product photos have not been
taken, and nobody has decided what the empty state should say. This delay is invisible in every plan
and appears in almost every project.
Stage four: testing, one to three weeks
Not "does it open" — proper testing on real
devices, including the cheap Android handset your actual users own rather than the flagship on the
developer's desk.
Bugs found here are not a sign the build went badly. They are the point of the stage. What matters is
that they are found by you and not by a one-star review.
Allow time for the fixes, not just the finding. A test cycle with no fix window built in is a test
cycle that produces a list nobody actions.
Stage five: submission, a few days to two weeks
Getting it into the stores is
administrative work with a queue attached.
Apple's review is usually quick these days, but the first submission of a new app is the one that
comes back — a missing privacy policy URL, no way to delete an account from inside the app, a demo
login that does not work for the reviewer. Google Play is generally faster on updates, and slower on
a brand-new developer account, which now goes through its own verification.
None of this is hard. It is just not instant, and it cannot start until everything else is done.
So what is the honest range?
For a straightforward business app — accounts, a handful of integrations, an admin panel, both
platforms from one codebase — roughly three to five months from agreement to store, assuming
decisions arrive on time and the content exists.
Simpler than that: six to ten weeks. A multi-role platform with payments, offline support and
reporting: longer, and the honest answer is that it should be broken into two releases rather than
estimated as one.
Launching on one store instead of two shortens the tail rather than the build, because it removes a
review process and a second round of device testing —
which platform to start on is the decision that
sets it.
The delays worth planning for
Almost every serious overrun on an app project comes from one of four places, and none of them is
code:
- A decision nobody has made, sitting with someone who does not know it is blocking anything
- Content that was assumed to exist
- A third-party account still in verification — payment gateway, SMS sender ID, developer account
- Scope that grew a little every week and was never re-estimated
The fix for all four is the same and unglamorous: a named person on your side who can decide, and a
written list of what version one contains.
What to do next
If you have a deadline that matters — a launch event, a funding milestone, a season — the useful
conversation is not "can you do it by then". It is which parts of the scope have to move to make the
date real.
Tell us the date and what it is for and we will tell you what fits inside it.
