App development cost depends on the work required to deliver and operate a defined application. Estimate 5 areas separately: user workflows, platform capabilities, integrations, quality requirements and ongoing operation. A screen count alone cannot describe that work, and a public number without an agreed scope would create a misleading expectation.
For a business asking what an app will cost, the useful first answer is a clear route to a written estimate. Identify what the app must do, what already exists and which uncertainties need investigation. This guide provides that route without publishing prices, inventing market ranges or promising a delivery date.
Which requirements change the estimate?
Android’s architecture guidance explains that an application involves components, UI and data responsibilities. The GOV.UK discovery-phase guide describes investigating the problem and constraints before committing to a solution. These sources support scoping principles, not a pricing formula or a timetable for a particular commercial project.
| Cost driver | Question to answer | Evidence that improves an estimate |
|---|---|---|
| User tasks | What must each kind of user complete? | Prioritised flows with normal and exception states |
| Platforms | Which devices and distribution routes are required? | Actual target scope rather than an assumed future expansion |
| Integrations | Which external systems must exchange information? | Current interface documentation and a representative test |
| Data | What is stored, changed, retained and recovered? | Data model and ownership decisions |
| Quality | What must be secure, accessible and reliable? | Explicit acceptance conditions |
| Operation | Who supports, updates and monitors the app? | Named responsibilities and a handover model |
The matrix is an original estimating aid. It does not imply that every app needs an elaborate architecture. It helps distinguish a simple requirement from one whose apparent simplicity hides several systems and failure states.
A login screen illustrates the difference. Displaying fields is only part of the task. The requirement may also include identity verification, recovery, permissions, session handling and support. An estimate should describe the agreed behaviour rather than count the screen as a single unit without qualifications.
Why do integrations and uncertainty matter?
An external service can introduce work beyond the visible interface. The app may need to authenticate, validate data, handle failures and recognise repeated requests. Ask whether the proposed interface is documented and available to the actual business. A service existing elsewhere does not establish account eligibility or access here.
Separate a proven integration from an assumed one. If nobody has tested a critical capability, record that uncertainty and plan a bounded investigation. A prototype can resolve a technical question, but it should not be represented as a complete production implementation.
Identify the existing material that can genuinely be reused. A working backend, approved design or maintained codebase may reduce some work while introducing migration or compatibility requirements. Do not count an asset as reusable until its condition, rights and fit are understood.
Keep scope changes traceable. A new user role, another platform or an offline requirement can change several parts of the system. Record the requested behaviour and its consequences before folding it into an earlier estimate. A change is easier to assess when its relationship to the original task is explicit.
How do you prepare a useful app brief?
Describe the problem before prescribing every screen. Identify the people involved, their starting information and the result they need. Include constraints such as an existing system that must remain or a device capability essential to the work.
Use examples with non-sensitive data. A redacted work order or a fictional appointment can explain the information flow without exposing customer records. Make clear which examples represent real rules and which are merely placeholders for discussion.
Use this original estimate-readiness sheet:
| Brief field | What to provide | Uncertainty to disclose |
|---|---|---|
| Problem | The current task and why it is difficult | Assumptions about users not yet checked |
| Users | Roles and the actions each may perform | Unresolved access or approval rules |
| Core flow | Entry, action and completed outcome | Missing business decisions |
| Exceptions | Failed, interrupted and disputed cases | Recovery behaviour not yet agreed |
| Data | Inputs, outputs and retention needs | Unknown source quality or ownership |
| Integrations | Actual systems and available documentation | Access or eligibility not established |
| Acceptance | Evidence that would demonstrate completion | Conditions requiring further investigation |
| Operation | Support, updates and account ownership | Responsibilities not yet assigned |
The sheet is an original practical artefact, not a commitment from a developer. It gives the estimator a defensible basis for discussing the work and identifying which questions prevent a reliable quote.
What should be included in a written estimate?
The estimate should identify the included scope, assumptions, exclusions and acceptance conditions. Distinguish implementation from optional work and ongoing responsibilities. Commercial terms must come from the authorised parties rather than a generic article or a copied proposal.
Explain how unresolved items are handled. An estimate can state what evidence is still needed and which decisions would change the scope. Hiding uncertainty inside a confident number does not make it disappear; it makes a later disagreement more likely.
Keep quality work visible. Testing, accessibility, security, release preparation and handover are not decorative extras when they are necessary to the agreed outcome. Describe the relevant work rather than assuming that every concern is automatically covered by the word “development”.
How can scope be reduced sensibly?
Prioritise the smallest useful end-to-end task. Removing a secondary feature can reduce work without making the main journey dishonest or unsafe. Removing failure handling from an essential payment or account action is a different decision and can undermine the outcome.
Use discovery to test whether an app is the right solution. A responsive website, process change or integration with an existing tool may address the need more directly. That is a design decision to investigate, not a reason to promise a cheap alternative without understanding the task.
Record the agreed scope before work begins and keep later changes reviewable. A useful estimate is a shared description of an outcome and its conditions, not merely a total detached from the application people expect.
Work through a scope difference without inventing a price
Consider a fictional app that records a completed site visit. Version A captures a note while online. Version B must also work without connectivity, attach photographs, distinguish staff roles and synchronise later. The second version adds data ownership, local storage, retry/conflict behaviour, permission cases and reconciliation; counting both as one “visit screen” hides the work.
Write each difference as an observable acceptance condition. For example: create a note offline, reconnect, and verify that one intended record arrives without silently replacing another person’s edit. Identify the actual backend interface and which failure remains unresolved. Ask the estimator to distinguish demonstrated reuse, implementation work and investigation. Then compare two written scopes on those same conditions. This produces a defensible comparison of what is included, without fabricating a monetary range, delivery duration or promised saving. The discovery source supports investigating alternatives; it does not set commercial terms for this example.
See web development for related implementation work. To request a scoped discussion, get started with the user task, platforms, integrations and the decisions already settled.
By Spout Team. AI-assisted drafting by Codex using the linked primary sources.