Price the first useful release, not the size of the idea.
A web app can be a focused internal tool, a customer portal, a marketplace or the core of a new product. Two projects with the same number of screens can carry completely different technical and operational demands, so a generic range often conceals more than it explains.
A useful estimate starts by defining the problem, primary users, essential workflow and conditions for a successful first release. It should separate known work from assumptions that need discovery or technical validation, then show which ongoing costs sit outside the initial build.
What determines the cost of a web app?
The main cost drivers are the number and complexity of user journeys, account roles and permissions, data model, integrations, administration tools, security requirements, design depth, migration, testing and launch support. Cost also changes with how much uncertainty must be resolved before development and how the product will be operated, monitored and improved after release.
Find the parts of the product that create real scope.
Count responsibilities and edge cases, not screens. A simple-looking interface can sit on top of a demanding set of rules.
Users, roles and permissions
A single public journey is different from a product with customers, staff, managers and administrators. Define what each role can see, create, change, approve and export, including what should happen when access changes.
Data and business rules
The structure, volume, sensitivity and lifecycle of data shape the architecture. Record validation rules, calculations, ownership, retention, search, import and export requirements before treating a form as a simple feature.
External integrations
Payments, identity, CRM, email, maps, accounting and third-party APIs introduce credentials, usage limits, failure states and vendor dependencies. Each integration needs an owner and a defined response when the external service is unavailable.
Operational tools
Most products need an unglamorous route for support, moderation, account recovery, corrections and reporting. Leaving administrative work out of the estimate moves cost into manual work after launch rather than removing it.
Security and assurance
Authentication, sensitive data, payments and privileged actions affect the required controls and depth of testing. State the risk and assurance level needed instead of treating security as a final checklist item.
Use discovery to turn uncertainty into decisions.
Discovery is not a promise to build every idea. Its job is to test whether the proposed product, scope and technical route are worth taking forward.
Define the user problem
Describe who is struggling, what they are trying to achieve and how the current process fails. This gives features a test: they remain only when they materially improve the journey or operation.
Identify the riskiest assumption
The greatest risk may be demand, a difficult integration, a legal constraint or whether users will understand a new workflow. Test that uncertainty before investing in the easiest screens.
Set the first-release boundary
Prioritise one complete, valuable path over a broad but shallow feature list. Record what is deliberately deferred and what architecture is genuinely needed now to avoid pretending that every possible future is a requirement.
Agree evidence and acceptance
Define the behaviour that will make a feature complete, who approves it and what evidence will be used. Acceptance criteria reduce the gap between a sentence in a proposal and the finished interaction.
Include the cost of operating the product.
The first deployment starts a live service. Hosting, support and change need owners even when the first release is intentionally small.
Infrastructure and usage
Hosting, storage, email, messaging, maps, search and other services may charge by usage. Ask which assumptions underpin the estimate and how cost will be monitored as activity grows.
Monitoring and incident response
Decide what will be monitored, who receives alerts, when support is available and how incidents are prioritised. Availability is an operating responsibility, not a design characteristic.
Maintenance and dependency change
Frameworks, packages, APIs and platform policies change. The support plan should distinguish security and compatibility work from requested product improvements and explain how updates are tested and released.
Learning and future releases
Plan analytics, feedback and decision reviews so the team can learn from real use. A backlog is not a commitment to build everything; it is a place to compare the next improvement against evidence and business value.
What a useful web app estimate should make visible.
The document does not need false precision. It does need enough structure for you to see what is included, uncertain and left for later.
Outcome and users
The business outcome, primary users and complete journeys included in the first release.
Functional boundary
Features, roles, permissions, integrations, administration and explicit exclusions.
Assumptions and risks
Items that still require research, prototype work, access to another system or a technical proof.
Design and content
Research, interface states, content responsibilities, accessibility and responsive behaviour.
Build and assurance
Environments, testing, security expectations, data migration, acceptance and launch responsibilities.
Ongoing operation
Infrastructure, third-party charges, monitoring, support, maintenance and the route for future releases.
Sources and further reading.
These primary sources inform the guidance above. Your project may need additional legal, security or accessibility advice for its own context.
How the discovery phase works
GOV.UK Service Manual: Guidance on defining a problem, understanding users and constraints, and deciding whether work should move into an alpha phase.
Application Security Verification Standard
OWASP: An open standard that can help teams specify and verify web application security requirements at an appropriate level of rigour.
Turn the idea into an estimate you can defend.
Subtle Standard can help define the user problem, first release, technical risks and operating responsibilities before shaping the design and build.
Web app costs questions.
Can I get a web app quote without discovery?
You can get an initial range or a quote for tightly defined work, but unresolved users, workflows and integrations will appear as assumptions, exclusions or contingency. A short discovery is most useful when it targets the decisions that could materially change the architecture or first-release scope. It should produce clearer evidence, not simply delay development.
Why do web app quotes vary so much?
Providers may be pricing different products under the same brief. One quote might include user research, interface states, an administration area, automated testing, deployment and support, while another covers only the visible customer path. Compare the functional boundary, risk assumptions, technical responsibilities, team composition and post-launch work before treating the totals as equivalent.
What is an MVP for a web app?
A minimum viable product is the smallest release capable of testing a meaningful value proposition with real users. It is not every planned feature delivered cheaply, and it should not remove essential security, accessibility or operational controls. A strong MVP completes one useful journey and creates evidence for the next product decision.
Should hosting and maintenance be included in the build price?
They should be visible, whether included for an initial period or priced separately. Ask about infrastructure, third-party services, monitoring, backups, incident response, dependency updates and requested product changes. Separating initial delivery from ongoing operation helps you compare the true first-year responsibility rather than only the cost to reach launch day.