On this page
Estimate the total cost of building and operating an app without presenting a false single-number quote.
There is no responsible universal price for “an app.” Cost follows the user jobs, supported platforms, workflow complexity, data and integrations, quality attributes, delivery team, evidence required, and uncertainty. A useful estimate exposes those drivers and changes as the team learns.
Define what is being estimated
State users, primary outcomes, web or mobile platforms, countries and languages, account model, data sensitivity, content, administrative work, integrations, expected scale, accessibility, offline behavior, support, and release target. Separate discovery, prototype, pilot, launch, and mature operations.
Include the full cost system
- Research, product management, information architecture, content, and UX design
- Client, server, data, integrations, migration, and administration
- Security, privacy, accessibility, performance, reliability, and compliance
- Automated and manual testing, devices, environments, release, and store work
- Hosting, vendor usage, monitoring, support, incident response, and maintenance
- Contingency, technical uncertainty, change, training, documentation, and exit
Choose an estimating method
| Method | Useful when | Main limitation |
|---|---|---|
| Analogous range | Early idea with comparable evidence | Differences can dominate |
| Bottom-up work model | Scope and architecture are clearer | False precision if unknowns remain |
| Time-boxed discovery | Risk is high or requirements conflict | Produces evidence before a build commitment |
Build an evidence-based estimate
- Write scope, exclusions, constraints, and assumptions.
- Break work into outcomes and enabling capabilities.
- Estimate ranges with the people doing the work.
- Identify dependencies and high-uncertainty items.
- Add operations, contingency, and decision reserves.
- Reforecast at each validated milestone.
Challenge missing work
- Budgeting only visible screens
- Assuming third-party APIs are free and stable
- Ignoring content, migration, administration, and support
- Treating a fixed deadline as evidence of fixed effort
Present a range with confidence
For each phase, show expected outcomes, work categories, lower and upper range, assumptions, dependencies, confidence, key risks, owner, and decision gate. Track estimate-to-actual variance by cause so later forecasts improve rather than merely becoming more detailed.
Build a cost range from work, not a market-price guess
The following is an illustrative planning model for a hypothetical authenticated scheduling app with a customer workflow, staff administration, notifications, and one external integration. The hours are scenario assumptions—not industry averages or a quote. Replace every range with estimates from the people who would perform the work.
| Workstream | Illustrative range | Evidence needed to replace it |
|---|---|---|
| Discovery and scope | 80–120 hours | Validated user jobs, workflow map, constraints, and exclusions |
| UX, content, and prototype | 120–200 hours | Tested flows, content inventory, states, and accessibility needs |
| Customer and admin capabilities | 360–600 hours | Acceptance criteria for accounts, scheduling, roles, and administration |
| Integration and data work | 120–240 hours | API documentation, failure behavior, migration volume, and ownership |
| Testing and quality controls | 180–300 hours | Device matrix, security review, accessibility checks, and release evidence |
| Release, training, and documentation | 60–100 hours | Store or hosting process, support handoff, runbooks, and training audience |
| First 90 days of operation | 100–180 hours | Monitoring, support demand, incident ownership, and planned improvements |
| Scenario total | 1,020–1,740 hours | Reforecast after prototype and integration tests |
Convert effort into a budget with variables you can substantiate:
Delivery range = estimated hours × loaded team cost + fixed third-party costs + risk reserve
Year-one range = delivery range + hosting and vendor usage + maintenance + support
The loaded team cost should reflect the actual staffing arrangement. Fixed costs should come from current written quotes. Set the risk reserve from named uncertainties rather than applying an unexplained percentage. Keep quoted, estimated, and unknown items separate so a precise-looking total does not conceal weak evidence.
- Map the smallest complete workflow using the MVP workflow guide.
- Write testable scope in a product requirements document.
- Estimate each workstream with the delivery team.
- Test the hardest integration and permission rules.
- Update the range and record why it changed.