odel.
Start a project

How long does it take to build an app? Realistic 2026 timelines, phase by phase

· By Oguz Delioglu, founder of ODEL

A simple app with one core workflow typically takes 3 to 7 weeks to build according to a 2022 GoodFirms survey of 267 firms, and 2026 vendor estimates put a simple MVP on both stores at 10 to 14 weeks (Idealogic, 2026). On top of the build, plan for fixed waits you cannot speed up: a D-U-N-S number for a company account, App Review, and for new personal Google Play accounts a 14-day closed test.

Timelines run late more often than budgets. Buyers describe apps still unfinished months after the promised date (see an Apple Developer Forums thread about paying the annual fee for an app that never launched on time). The fix is not a faster developer. It is a smaller first version, decisions made early and the store paperwork started on day one.

What the sources say

Source and date Type Simple / MVP Medium Complex
GoodFirms, May 2022 Survey of 267 firms 3 to 7 weeks 8 to 14 weeks ("complex") 13 to 19 weeks ("advanced")
Idealogic, Oct 2026 Vendor estimate 10 to 14 weeks 14 to 20 weeks 20 to 28 weeks
TechnBrains, Aug 2026 Vendor estimate 6 to 12 weeks 4 to 7 months 7 to 12+ months
Teamseven, Sept 2026 Vendor estimate (SaaS) 8 to 10 weeks (one workflow) 10 to 14 weeks (2 to 3 workflows, billing) 14 to 18 weeks (plus integrations)
Clutch, updated Sept 2026 Client reviews Average across all projects: about 11 months

Two notes. Clutch's 11-month average covers every project size reviewed on the site, including large ones, so it is not a forecast for a small app. And a vendor benchmark of its own 30 builds reported a median of 12 calendar weeks from kickoff to first live release (Wavect, 2026). We found no independent recent survey of MVP timelines; besides GoodFirms and Clutch, every figure above comes from a company that sells development.

Teamseven also warns that a SaaS MVP quoted at under 6 weeks is usually a template (2026). That is worth knowing when a quote looks too fast.

The phases, and what makes each one slow

  1. Discovery and scope. Agreeing on who the users are, the one job the first version does, platforms and how it makes money. Slow when the founder is still deciding what the product is. A written brief speeds it up: use our app brief template.
  2. Design. Clickable screens before code. Slow when feedback arrives in rounds weeks apart, or when the brand does not exist yet.
  3. Build. Features in working slices you install on your phone. Slow when scope grows mid-build, when an outside API is unclear, or when content (texts, images, prices) is not ready.
  4. Store setup. Developer accounts, app records, privacy details, subscriptions, screenshots, store text. Slow when nobody started the accounts early.
  5. Review and release. App Review and Google Play checks. Slow when the app is incomplete, crashes or lacks a demo account.
  6. First update. Real users find real issues. Plan for it before you announce launch.

Fixed waits you should plan around

These come from Apple and Google, not from your developer:

  • D-U-N-S number for a company account: Apple says to allow up to 5 business days from Dun & Bradstreet, expediting does not shorten it, and to contact D&B if it takes over two weeks (Apple). Google also requires D-U-N-S for organization accounts (Google).
  • App Review: Apple says it reviews at least 50 percent of submissions in under 24 hours and 90 percent in under 48 hours (Apple, 2026). A rejection restarts that clock.
  • Google Play closed test: personal developer accounts created after November 13, 2023 must run a closed test with at least 12 testers opted in for at least 14 days before production access (Google). Put at least two extra weeks into an Android plan if this applies to you.

The biggest avoidable delay is a rejection. Apple says over 40 percent of unresolved issues relate to guideline 2.1, App Completeness: crashes, placeholder content, broken links, missing demo accounts (Apple). See why Apple rejects apps and how to avoid it.

Planning checklist

Start these on day one, in parallel with design:

  • Decide the legal entity that will own the app and start the D-U-N-S lookup if it is a company. Guide: set up Apple and Google developer accounts for your company.
  • Enroll in the Apple Developer Program and register on Google Play under your own name or company.
  • Write the privacy policy and support page; both links are required.
  • Recruit testers early if you need the Google closed test.
  • Freeze the first-version feature list in writing. New ideas go to a "version 2" list.
  • Agree on milestones you can install and test, with dates.
  • Book time each week to review builds. Slow feedback is a common cause of slipping.
  • Prepare content: texts, images, prices, subscription names.

Questions to ask any developer about their timeline:

  • Which phases does the estimate include: store setup, review, the first fix release?
  • What happens to the date if I add a feature?
  • When will I first install a build on my own phone?
  • What do you need from me, and by when?

When ODEL fits, and when it does not

ODEL is a one-person studio that ships its own iPhone and Android apps. We do not promise fixed timelines on a website: after a discovery call you get a written scope and a phased plan with milestones you install on your phone. Because the same person designs, builds and submits the app, there are no handoffs between teams, and App Review is routine work for us. Good fits: an MVP, an iPhone app or an App Store launch.

Not a fit: a hard launch date for a large product that needs several developers working in parallel, 24/7 on-site support, or enterprise integrations on a short fixed deadline. A larger agency can staff that in parallel; one person cannot. If you need to be live this week, an existing SaaS or a no-code tool will get you there faster. To get a phased plan for your idea, start here.