How long does it take to build an app? A defensible timeline and cost model

Last substantive review: August 2026.

“How long will the app take?” sounds like a request for one date. It is actually a request for a decision model. A useful answer must connect product scope, technical constraints, delivery capacity, acceptance evidence, and unresolved risk. Without those inputs, a four-month estimate and a nine-month estimate can both sound plausible while neither helps a buyer approve the work.

This guide shows how to create a defensible timeline and cost range for a production application. It is written for CTOs, vice presidents of engineering, product leaders, and procurement teams that need more than a sales estimate. The aim is not to make uncertainty disappear. It is to show which assumptions drive the range, what evidence closes each phase, and when the forecast should be updated.

The method works for a new customer-facing product, a bounded internal application, or a difficult slice of an inherited backlog. Those are different delivery problems, so they should not share one generic “app development” price.

Start with the decision the estimate must support

An estimate for annual budgeting can tolerate a wider range than an estimate used to sign a statement of work. An estimate for a board plan needs clear contingency and milestone dates. An estimate for backlog triage may need only enough precision to choose between repair, replacement, and de-scoping.

Write down the decision, the date on which it must be made, and the confidence required. Then record a baseline: the users, workflows, platforms, integrations, data, quality requirements, operating environment, and launch obligations included in the estimate. A list of screens is not a baseline. It misses background jobs, permissions, failure states, administration, analytics, migrations, support tooling, and release work.

The baseline also needs an explicit “not included” list. If native iOS, historical-data migration, SOC 2 evidence, localization, offline operation, or a hardware certification is not in the model, say so. An exclusion is useful only when the buyer can see it before approval.

Model the constraints before estimating the work

App effort tends to be shaped by a small set of constraints, but their combinations are specific to each system:

• Product surface: user roles, workflows, state transitions, administration, notifications, reporting, and exception handling.
• Platform: web, mobile, desktop, embedded device, kiosk, or several of these, including the versions and form factors that must be supported.
• Data: source quality, migration volume, retention, deletion, auditability, residency, and reconciliation.
• Integrations: API maturity, sandbox access, rate limits, vendor approval, webhooks, identity, and ownership when an external service fails.
• Quality: performance, accessibility, security, privacy, availability, browser or device coverage, and the evidence needed for acceptance.
• Inherited systems: build reproducibility, test coverage, architecture, unsupported dependencies, undocumented behavior, and access to people who understand the system.
• Delivery environment: team availability, review turnaround, procurement, legal review, app-store or customer release processes, and production access.

These are estimate inputs, not caveats to add at the end. If a payment partner has not granted sandbox access, the integration is a dependency with an owner and an assumption. If a hardware protocol has no reliable documentation, diagnosis belongs in the plan. If the acceptance standard includes keyboard navigation and screen-reader behavior, accessibility belongs in design and implementation, not in a final compliance pass. The W3C’s current Web Content Accessibility Guidelines 2.2 provide testable success criteria for web content; the applicable conformance target still needs to be agreed for the product.

Turn the baseline into a work and dependency model

Break the application into work packages that can be estimated and accepted. A package might be “customer invitation and role assignment,” not “frontend.” It should include the user behavior, service behavior, data changes, failure handling, tests, observability, documentation, and release work needed to call that slice complete.

Estimate effort by role rather than multiplying a guessed calendar duration by one blended team. Product design, application engineering, QA, infrastructure, security review, data work, and technical leadership do not appear in the same proportion on every package. Some can overlap; others cannot. A designer can prepare the next workflow while engineers build the current one, but a migration rehearsal may have to wait for representative data and a stable schema.

Then connect the packages in a dependency network. Identify which work can proceed in parallel, which external inputs have fixed decision dates, and which chain controls the earliest credible launch. The U.S. Government Accountability Office’s Schedule Assessment Guide describes a reliable schedule as comprehensive, well-constructed, credible, and controlled. Although the guide addresses government programs, those tests are useful for product delivery: missing work, broken logic, unsupported duration assumptions, and an uncontrolled baseline weaken any schedule.

Do not hide dependencies inside a general contingency percentage. Name them. Assign an owner. Define the evidence that closes them. A realistic range can then account for unresolved items without pretending the team controls a vendor, a customer security review, or an app-store decision.

Estimate hours, cost, and uncertainty separately

A simple model is:

Estimated hours = work-package effort + QA and release effort + documentation and coordination + explicit risk reserve.

Estimated cost = hours by role and rate + nonlabor costs.

Nonlabor costs may include cloud environments, observability, licenses, test devices, data providers, app-store accounts, penetration testing, or vendor implementation fees. They should not disappear into the engineering rate.

Keep the estimate range separate from the commercial model. An hourly engagement, a capacity subscription, and a fixed-price milestone can all use the same underlying effort model. The contract determines how risk and change are handled; it does not change the amount of work the system requires.

The GAO’s Cost Estimating and Assessment Guide emphasizes scope, assumptions, data, a point estimate, sensitivity analysis, risk and uncertainty, documentation, approval, and updates. For software, historical delivery data is more useful than a generic industry velocity. Calibrate against work your team has actually completed under similar conditions, then explain where the new system differs.

Use a range while material uncertainty remains. The lower end assumes the documented favorable conditions hold. The upper end should reflect identified risk and credible variation, not an arbitrary doubling rule. If a single dependency can move the forecast beyond the stated range, make it a decision gate rather than burying it in the estimate.

Illustrative scenarios, not universal app prices

The ranges below demonstrate the math. They are not quotes, benchmarks, or promises. Each assumes 40 productive hours per full-time-equivalent week for arithmetic only; actual staffing, holidays, coordination, part-time specialists, and client responsibilities change calendar duration. “FTE-equivalent” describes capacity, not a promise that every role is staffed by one full-time person.

Scenario A: bounded operational pilot

Assumptions: one primary user group, a narrow workflow, a web interface, an existing identity provider, one documented integration, no historical migration, and a defined production environment. Two FTE-equivalent people over eight to twelve weeks produces 640 to 960 hours. At Horizon Labs’ product-team range of $100–$120 per hour, the illustrative labor range is $64,000 to $115,200.

This could be enough for a production pilot only if the workflow and acceptance bar are genuinely bounded. Add native mobile clients, complex roles, customer-specific configuration, regulated data, an unstable vendor API, or broad reporting and this scenario no longer applies.

Scenario B: customer-facing operational application

Assumptions: several user roles, responsive web delivery, product design, multiple core workflows, two or three integrations, administrative tools, automated testing, observability, production release, and a moderate data migration. Three to four FTE-equivalent people over sixteen to twenty-eight weeks produces 1,920 to 4,480 hours. At $100–$120 per hour, the illustrative labor range is $192,000 to $537,600.

The width is intentional. Integration readiness, migration quality, security requirements, and decision latency can change how much work is sequential. The estimate should narrow after discovery produces interface contracts, representative data, a tested technical path, and accepted workflow designs.

Scenario C: inherited specialist backlog slice

Assumptions: an existing system, one technically difficult backlog area, access to source and environments, and a goal of diagnosis plus delivered fixes rather than a full new application. One or two senior specialists over four to twelve weeks produces 160 to 960 hours. At Horizon Labs’ specialist range of $150–$200 per hour, the illustrative labor range is $24,000 to $192,000.

This is not a full-app estimate. It is a way to size a bounded intervention such as an embedded-device communication problem, an AI pipeline, a performance bottleneck, or a release blocker. The first gate may be a paid diagnostic that replaces assumptions with evidence before the buyer approves a larger tranche.

Use phase gates to earn the next commitment

A long build becomes easier to govern when each phase ends with evidence and a decision. The labels can vary, but the control points should be explicit.

Gate 1: estimation baseline

Approve the target users, workflows, exclusions, constraints, decision owners, commercial lane, and estimate range. Record assumptions in a log with an owner and a date for validation. If the inherited system cannot be built or accessed, the next commitment is diagnostic work, not a production promise.

Gate 2: architecture and experience

Approve the main workflow designs, data model, integration contracts, security boundaries, accessibility target, deployment approach, and technical spikes for the largest unknowns. The evidence may include prototypes, architecture decisions, an integration proof, and a revised work breakdown. Update cost and schedule when these findings change the baseline.

Gate 3: vertical delivery slices

Build complete, testable paths through the system rather than isolated layers. A slice should include interface, application logic, data behavior, authorization, error states, telemetry, and automated tests. Demonstrate against acceptance criteria at a predictable cadence. Track forecast-to-complete, dependency status, defect trends, and decisions waiting on the client.

Gate 4: acceptance readiness

Complete the agreed test matrix: functional scenarios, role and permission cases, migration reconciliation, browser or device coverage, performance thresholds, accessibility checks, security findings, operational alerts, and known limitations. The NIST Secure Software Development Framework gives software producers and purchasers a common set of secure-development practices that can be integrated into a delivery lifecycle. Use the controls that apply to the system and contract; do not claim that one checklist makes the product secure.

Gate 5: production readiness and launch

Confirm production access, configuration, secrets, rollback, backup and restore, support ownership, incident contacts, dashboards, runbooks, release approvals, and customer communications. Rehearse migration and rollback when data changes are material. A deployment is not accepted merely because the build passed in a staging environment.

Gate 6: observation, handoff, and warranty

Define the observation window, launch metrics, defect triage, documentation, repository and account transfer, support responsibilities, and the transition into warranty or ongoing capacity. Acceptance should identify which known limitations are approved and which defects remain open.

Write acceptance evidence before the work starts

“Works as expected” is not an acceptance criterion. Describe the actor, starting state, action, expected result, permission boundary, failure behavior, and evidence. For an imported order, for example, acceptance might require an authorized operations user to import a representative file, see rejected rows with reasons, reconcile accepted totals, retry safely, and find an audit record.

Procurement should be able to connect invoices to accepted milestones or recorded capacity. Engineering should be able to connect the same milestones to tests, demonstrations, and production-readiness evidence. This shared definition reduces the end-of-project argument in which product believes a feature is complete, QA sees unresolved defects, and finance sees an undefined deliverable.

For more detail on structuring a bounded commitment, see Horizon Labs’ guide to scoping a fixed-price feature milestone. If the commercial discussion is tied to a measurable business result, review the cautions in the outcome-based pricing guide. Outcomes require an attributable baseline, a measurement period, and a clear account of factors neither party controls.

Choose the delivery lane that matches the uncertainty

Horizon Labs uses two distinct lanes because a product build and a specialist intervention have different staffing and risk.

• Product team, $100–$120 per hour: a coordinated delivery group covering full-stack engineering, QA, launch, and the agreed handoff. Qualifying engagements include a six-month code warranty; the signed statement of work defines its exact scope, start date, process, and exclusions.
• Senior or specialist engineering, $150–$200 per hour: experienced engineers brought into an inherited system to diagnose and clear difficult backlog, including areas such as embedded systems, IoT, AI engineering, platform reliability, or complex integrations. The engagement should start with a bounded objective and direct access to the evidence needed to work quickly.

A higher specialist rate is not a claim that every task will finish faster. It is appropriate when the work requires scarce experience, independent technical judgment, or rapid diagnosis in a system the team did not design. Routine product delivery should not be relabeled as specialist work.

Horizon Labs’ sustained work with MKProducts is relevant to the second lane. From November 2024 through July 2026, Horizon engineers worked in an Android and embedded orbital-welding context involving USB communication, kiosk behavior, weld logs, and device debugging. That history establishes continuity in a specialist backlog environment. It is not presented here as a quantified speed, reliability, or business-outcome claim.

Give approvers a forecast they can audit

The approval packet does not need to be long. It should contain the baseline, exclusions, work breakdown, dependency map, range and confidence, rate assumptions, nonlabor costs, phase gates, acceptance evidence, client responsibilities, change process, warranty language, and current risk register. Show the source and date for each material assumption.

Refresh the forecast at the gates and whenever a material assumption fails. Keep the original baseline so leaders can distinguish scope change from estimate error and external delay from delivery performance. A controlled forecast becomes more useful over time because it records what the team learned.

If you need a defensible estimate for a new product or a bounded senior-engineering intervention, contact Horizon Labs. Bring the current backlog, architecture, target date, known constraints, and acceptance obligations. The first useful output should be an assumption log and a decision path, not an unsupported date.

Frequently asked questions

How long does it take to build an app?

There is no reliable universal duration. A defensible range comes from the defined product surface, platform and integration constraints, acceptance standard, available capacity, dependencies, and risk. A bounded pilot may fit into weeks, while a production application with migrations, compliance work, or multiple platforms may require several months.

How should a company estimate app development cost?

Break the work into testable packages, estimate effort by role, add QA, release, documentation, coordination, and explicit risk reserves, then price the resulting hours at the applicable rates. Include nonlabor costs such as cloud services, licenses, devices, and app-store accounts. Update the estimate when assumptions or evidence change.

What usually changes an app timeline?

The largest changes often come from scope growth, inherited-code uncertainty, data migration, third-party integrations, security or accessibility requirements, device constraints, slow decisions, and acceptance work discovered late. Put these items in the dependency plan instead of treating them as background details.

Should app development use a fixed price or an hourly model?

Use a fixed price when the deliverable, exclusions, dependencies, and acceptance evidence are genuinely bounded. Use an hourly or capacity model when the backlog is changing, discovery is still reducing uncertainty, or specialists must diagnose an inherited system. A phased engagement can use both.

What does Horizon Labs' six-month code warranty cover?

For qualifying product-team engagements, Horizon Labs offers a six-month code warranty for defects in the delivered code. The signed statement of work controls the exact coverage, start date, response process, and exclusions; new scope, third-party changes, and operating-environment changes are not automatically warranty work.