Web App Development Cost: How to Build a Complete Budget

Why a feature list is not enough to price a web app

Two web apps can both include sign-in, a dashboard and report export while requiring very different effort. A single-role system with manual data entry is unlike one that needs branch-level permissions, ERP synchronisation, thousands of records and an audit trail for every decision. Feature names do not describe the business rules, exceptions or risk inside them.

An early estimate should be a range or a set of scenarios rather than false precision. The GOV.UK Service Manual treats discovery as the phase for understanding users, the problem and constraints before deciding whether to proceed. For a business application, discovery should identify the first useful slice, technical risk and the assumptions that move the budget.

• ✓Core workflows, exceptions and ownership at each step.
• ✓User roles, data boundaries and authorisation rules.
• ✓Required systems, API quality and migration needs.
• ✓Availability, performance, audit and post-launch support expectations.

An estimate is useful only when the business knows which outcome it buys, which assumptions it relies on and what remains to operate after launch.

Seven cost groups that belong in the budget

The first group is discovery and design: interviews, workflow mapping, data checks, prototyping, architecture and acceptance criteria. Product delivery then covers interface, backend, database, permissions, administration and testing. Counting development hours while omitting these areas often returns the cost as rework.

The remaining groups are data migration, third-party integration, production readiness, secure development and operations. NIST SSDF recommends tracking security requirements, risks and design decisions across the development lifecycle; this work needs an estimate rather than being left to a final check. After launch, infrastructure, monitoring, backup, support, dependency updates and roadmap changes continue.

• ✓01. Discovery, prototype and testable specification.
• ✓02. Experience design, architecture, data and APIs.
• ✓03. Development, functional testing and acceptance.
• ✓04. Migration, integration and third-party services.
• ✓05. Security, performance, logging, backup and recovery.
• ✓06. Infrastructure, monitoring, support and incident handling.
• ✓07. Maintenance, business change and roadmap improvement.

A budget formula the business can inspect

A useful formula is team cost by delivery stage plus third-party services, infrastructure and a contingency tied to known risks. Team cost comes from the capabilities required, duration and real allocation. Multiplying screen count by one rate is weak because one screen can contain very different business rules.

Ask for three scenarios: the smallest testable slice, the intended operational release and optional expansion that is not yet committed. Each scenario should state functionality, data, integrations, quality criteria and exclusions. AWS Well-Architected recommends analysing workload components, modelling cost at different usage levels and reviewing it over time, so the operating forecast should include a baseline and a growth case.

• ✓Baseline scope: the capabilities needed for one complete end-to-end flow.
• ✓Assumptions: whether data, APIs, test accounts and decision makers are available.
• ✓Variables: users, transactions, storage, environments and support levels.
• ✓Contingency: connected to a described risk, not an unexplained percentage.

How to read an estimate and expose costs hidden after signature

A good proposal connects deliverables to acceptance criteria. It states feedback rounds, environments, test data, supported devices, documentation, training and handover. It also distinguishes estimates from fixed commitments and explains how scope changes are approved.

Check ownership of the repository, data, cloud accounts, domain and documentation. Ask who pays for email, storage, maps, AI, SMS or payment services; which usage limits apply; and how cost changes with traffic. A low build price that locks the business into supplier-owned accounts can create a much larger switching cost later.

• ✓Deliverables, delivery schedule and acceptance criteria.
• ✓Exclusions, dependencies and each party's responsibilities.
• ✓Ownership of code, data, infrastructure and credentials.
• ✓Defect warranty, operational support and pricing for new change.

How Friday Works estimates a web app project

Friday Works starts with the workflow, users and outcome that need to change. Focused discovery commonly takes 1–3 weeks when data and process owners are available. Its outputs include workflow scope, risk, a prototype or specification, proportionate architecture and a release plan that supports a clearer estimate.

For a focused MVP, a typical planning range is 8–14 weeks; substantial migration, multiple integrations, security requirements or higher availability are divided into stages. This is not a fixed price list. A proposal is confirmed only after important assumptions are tested and the business selects the investment level that matches the evidence it needs.

• ✓One value-producing slice rather than disconnected screens.
• ✓An estimate range with assumptions, risks and change conditions.
• ✓Build cost and operating cost shown separately.
• ✓Code, data, environments and handover documented in the proposal.