How long does a custom app usually take to reach its first release?
A reliable number of weeks requires a defined first-release scope, target platforms, existing assets, and external dependencies. Calendar time comes from the work needed to meet acceptance, the team's effective capacity, and the longest dependency chain, with separate uncertainty for testing, migration, account and licence readiness, payment or mapping integration, privacy remediation, and store review. Wavesteam gives a range and confidence after the prototype and dependency register—not a universal six-to-eight-week promise.
“First release” also needs definition. A demonstration package, invitation beta, downloadable store release, and production service accepting real payments are different outcomes. A demo may use simulated data; production needs controlled accounts, monitoring, backup, privacy disclosure, and operating staff.
When planning milestones, resources, and acceptance, also compare How long does it take to build and launch a two-client software system?; the linked guidance adds context that should be considered in the same decision.
| Target | Necessary evidence | Common longest dependency | Completion |
|---|---|---|---|
| Clickable prototype | Roles, flows, states, copy | Business decisions and content | Representative users complete a walkthrough |
| Internal demo | Core UI, isolated or mock data, known limits | Technical feasibility and interface samples | Script runs reliably in the demo environment |
| Invitation beta | Real backend, accounts, logs, test distribution | Devices and supplier sandbox | Named users complete the core loop and report results |
| Store release | Production config, privacy, monitoring, rollback, review material | Developer account, licence, store review | Available in target market and healthy in production |
| Operable transaction release | Payment, reconciliation, support, refund, incident process | Merchant account, contracts, operating roster | Real transaction and exception rehearsal complete |
Estimate work packages, not screens. Each package defines input, normal and exceptional paths, data, permission, sample acceptance, and dependencies. Product, design, client, backend, test, and operations work is estimated by the people doing it, then arranged according to what can run in parallel. Shared business logic does not halve two-platform work, and native work does not always double it; camera, Bluetooth, background execution, push, and payment affect the tradeoff.
Capacity is not headcount multiplied by working days. Additional people create communication and integration cost and still perform reviews, fixes, and meetings. The strongest forecast comes from the same team's recent completed work under a similar stack and definition of done. In a first engagement, use scope and risk ranges and forecast again after the first iteration rather than presenting the optimistic date as certainty.
Store review is an external window, not development effort. Apple, Google, and domestic stores change account, testing, privacy, category, and review requirements. List accounts, entity evidence, contracts, policy, test access, and store assets as client dependencies with latest-ready dates. “Ready to submit” is not “approved,” and rejection and resubmission are risks rather than a fabricated one-to-three-day allowance. Apple's App Review Guidelines are a primary reference, while actual status remains in App Store Connect.
The plan shows a baseline, target range, and material risk. Unavailable supplier test access remains an uncommitted dependency. Scope additions, decision delay, interface change, and review rejection produce a written impact and revised forecast while preserving the original baseline.
Keep one complete path by which a user obtains the core value, plus necessary administration, permissions, monitoring, and exit. Move report polish and low-frequency settings later. Do not remove payment security, personal-data deletion, backups, or high-risk exceptions merely because the release is an MVP. Remove the underlying data and workflow together rather than leave half an inoperable module.
Progress is proven by work packages that meet the definition of done, accessible versions, tests, blockers, unresolved decisions, defect trend, and dependency state—not “80% complete.” Wavesteam first delivers the first-release scope, prototype, breakdown, and dependency register, then a calendar range. When the market date is fixed, we cut lower-value scope and identify non-negotiable launch gates instead of promising overtime will fit everything. The service process explains the delivery stages.