How much does web app development cost in the UK?

Use transparent planning bands, not a universal app price

A web app is a working service delivered through a browser, not a fixed product with a standard UK price. A customer portal using an established identity provider and documented application programming interfaces is materially different from a marketplace with payments, moderation, complex permissions, data migration, audit history, and round-the-clock operational needs. The responsible first answer is therefore a conditional range tied to a named release and its evidence requirements.

For early planning, this guide uses three editorial bands. A focused validation phase is modelled as 30–50 person-days at £500–£600 per person-day, producing £15,000–£30,000. A controlled first live release is 80–125 person-days at £500–£800, producing £40,000–£100,000. A complex or higher-assurance service is 160–300+ person-days at £625–£1,000, producing £100,000–£300,000+. One person-day means one person working for one day; it is not a calendar day or a whole team day. The rates are hypothetical blended assumptions chosen to show how role mix and specialist assurance change a model; they are not observed supplier rates. This editorial method was last reviewed on 16 August 2026.

Those arithmetic bands are not market averages, Blancc prices, quotations, guarantees, or evidence that a particular project belongs in a band. They exclude VAT, client staff time, usage-based infrastructure, licences, payment fees, specialist audits, data acquisition, and other third-party costs unless a proposal expressly includes them. Reproduce the model by listing the roles and days required, applying the stated day-rate assumption, then adding named external costs and an explicit risk allowance rather than copying the headline range.[7]

See how customer portal journeys, permissions, integrations, data and support shape a portal scope ↗

• Focused validation scenario: 5–8 research and service-design days, 8–12 product and interface days, 10–18 architecture and prototyping days, and 7–12 assurance and delivery days
• Controlled release scenario: 10–15 discovery and design days, 50–75 engineering days, 12–20 assurance days, and 8–15 release and delivery days
• Complex-service scenario: 15–30 research and design days, 100–180 engineering days, 25–45 assurance days, and 20–45 release and operational-readiness days
• State whether VAT, expenses, licences, infrastructure, client time, and contingency are included
• Replace every illustrative input with a discovery-backed role plan and estimate before authorising a build

Define the release boundary before estimating delivery

Start with the user problem, the people affected, the complete service journey, the operational context, and the decision the first release must support. GOV.UK's discovery guidance says teams should understand the problem before committing to build and should examine users, constraints, the wider journey, opportunities, and success measures. That guidance is written for public services, but its separation of problem discovery from solution delivery is a useful commercial budgeting discipline.[2]

Describe the release in observable terms: which users can enter, what each user can do, which data enters or leaves, which exceptions must be handled, what an administrator can control, and what evidence counts as acceptance. Include authentication, permissions, notifications, imports, exports, search, reporting, support routes, audit records, content management, and failure recovery where they are genuinely needed. Screen counts alone conceal the rules and states that engineering and testing must cover.

Also test whether bespoke software is necessary. An existing product, process change, content intervention, or integration may solve the important problem with less ownership risk. The GOV.UK Service Manual's commercial-off-the-shelf guidance says technology should not be committed to before the problem is understood and alternatives are tested; private buyers can use the same question without adopting government procurement rules. Budget discovery to compare options rather than using development momentum as proof that custom code is correct.[3]

• Name the primary users, jobs, service channels, and measurable outcome
• List the happy path, important exceptions, administrative work, and support path
• Identify existing products, process changes, and integrations considered before custom build
• Define what the first release will prove and which roadmap items remain outside it

Price the whole product system and its assurance work

The visible interface is only one part of a web app budget. Delivery can require user research, service design, content design, interaction design, technical architecture, frontend and backend engineering, data modelling, infrastructure, quality assurance, accessibility, security, analytics, documentation, release management, and project leadership. A smaller multidisciplinary team can cover several roles, but the estimate should still expose the responsibilities so essential work does not disappear between job titles.

Data and integration uncertainty deserve separate attention. Clarify data ownership, quality, volume, retention, migration, export, deletion, hosting region, and lawful use. For every external system, verify documentation, authentication, rate limits, sandbox access, error behaviour, service levels, change policy, and commercial terms. A seemingly simple integration becomes costly when the supplier cannot provide realistic test data, stable interfaces, or a person authorised to resolve decisions.

Assurance is delivery work. The W3C describes WCAG as a shared international accessibility standard, while the UK ICO says data protection should be integrated at design and throughout the processing lifecycle. The NCSC's secure development principles address maintainable code, development environments, repositories, build and deployment pipelines, continual testing, and planning for security flaws. A proposal should connect applicable accessibility, privacy, and security requirements to activities, evidence, owners, and acceptance criteria instead of offering a generic compliance label.[4][5][6]

• Map research, design, engineering, assurance, delivery, and operational responsibilities
• Run a technical spike where one integration or data constraint could reverse the estimate
• Specify browser, device, assistive-technology, performance, and security test coverage
• Record privacy purposes, data flows, retention, access, deletion, and incident responsibilities
• Treat specialist legal, security, or accessibility advice as a named external cost where required

Separate build cost from the cost of operating a live service

Launch changes the type of work; it does not end the work. A live web app needs hosting, domains, certificates, databases, storage, email or messaging providers, monitoring, backups, recovery, dependency updates, security response, user support, analytics governance, and a release process. Usage-based providers can make the operating total sensitive to traffic, stored data, messages, model calls, payment volume, or third-party requests, so one monthly hosting number may be misleading.

Build a twelve-month operating model with low, expected, and stress scenarios. For each service, record the pricing unit, included allowance, forecast volume, overage rate, owner, and exit route. Add planned maintenance person-days, incident cover, support hours, accessibility fixes, browser changes, and mandatory provider migrations. The GOV.UK Service Standard includes operating a reliable service and iterating frequently because a service must remain usable after its first release; the same lifecycle reality applies to commercial web apps.[1]

Ownership terms also affect future cost. Confirm who controls source repositories, deployment accounts, cloud resources, encryption keys, domains, data exports, monitoring, design files, and third-party subscriptions. Require usable documentation and an exit handover rather than relying on an informal promise that assets can be transferred later. A lower build fee can create expensive dependency when only the supplier can deploy, diagnose, or retrieve the service.

• Model twelve months of infrastructure, provider usage, support, and maintenance
• Name service-level expectations, alert routes, recovery objectives, and incident ownership
• Confirm repository, account, credential, domain, data, and documentation control
• Require export and supplier-exit procedures before the first production release

Compare proposals with a common commercial worksheet

Give each supplier the same brief and require a response at the same level of detail. Ask for phase objectives, deliverables, team roles, person-days, rates or commercial model, assumptions, client dependencies, third-party costs, exclusions, contingency, milestones, feedback windows, acceptance criteria, intellectual-property terms, warranty, support, and change control. If a supplier cannot expose person-days because it offers a fixed fee, it can still explain the assumed scope, capacity, risk allocation, and events that trigger a change.

Normalise the totals before comparing them. Move optional features into a separate column; add omitted licences, infrastructure, audit, migration, and operating costs; note internal client effort; and flag different warranty or support periods. Then score proposals against user understanding, solution fit, delivery evidence, assurance approach, team capability, operational ownership, and total first-year cost. The lowest initial figure is not automatically the lowest comparable cost.

Authorise work in evidence-led stages. A discovery can end with a decision not to build; a prototype can test a risky journey; a technical proof can test an integration; and a controlled release can demonstrate real operation. Tie each stage to a decision, budget ceiling, deliverables, and exit criteria. Update the estimate when evidence changes the release instead of preserving an early number after its assumptions have failed.

• Issue one common brief and one proposal response template
• Compare like-for-like first-year totals rather than headline build fees
• Score scope clarity, evidence, assurance, ownership, and team fit alongside cost
• Tie payments and continuation decisions to reviewable outputs and agreed gates
• Keep an approved change log showing cost, schedule, and acceptance impact