How Much Does a Custom Web Application Cost in the UK? A 2026 Guide

Ask five UK suppliers to price the same web application and you can easily receive five numbers that sit tens of thousands of pounds apart. Usually none of them is wrong. They are pricing different things, at different day rates, with different assumptions about what "finished" means. This guide explains where the money goes, gives you a way to estimate a realistic range before you speak to anyone, and lists the running costs that most quotes leave out.

Want a figure for your own project? Our free web application cost calculator applies the method in this guide to the features you choose and gives you a range, a timeline and running costs in seconds.

If you are still deciding whether a custom build is the right move at all, our guide on custom web application development sets out when bespoke software pays for itself and when a product off the shelf is the better choice.

How suppliers actually arrive at a price

Almost every quote for bespoke software is built the same way underneath, even when it is presented as a single fixed figure.

price = estimated days of effort × day rate + fixed costs + contingency

The day rate depends on who does the work. IT Jobs Watch tracks advertised contract rates across the UK. For the six months to 5 November 2026 it reported:

Advertised UK contract day rates, six months to 5 November 2026

Role	10th percentile	25th percentile	Median	75th percentile	90th percentile
Full-stack developer	£363	£425	£500	£570	£651
React.js developer	£384	£425	£520	£656	£938

The estimated days are where quotes really diverge. One supplier assumes you will supply finished designs and content; another includes discovery workshops, design, automated tests and a launch period. Neither is padding. They simply describe different projects.

Fixed costs cover things such as hosting setup, third-party subscriptions and certification. Contingency is the allowance for what nobody can know yet. A quote with no contingency at all usually means the risk has been moved onto you through change requests later.

What drives the number of days

Six factors explain most of the difference between a small build and a large one.

1. User roles. Each type of user (customer, staff, manager, administrator) needs its own permissions, screens and tests. Three roles are much more than three times the work of one.
2. Integrations. Connecting to your accounting system, CRM, calendar or a supplier's API is often the riskiest part of the project, because you depend on someone else's documentation and limits. Our article on API integrations that hold businesses together explains why they deserve their own line in the budget.
3. Payments. Taking money adds checkout flows, refunds, receipts, failed-payment handling and reconciliation. A provider such as Stripe handles the card processing, but the business logic around it is still yours to build.
4. Data migration. Moving years of records out of spreadsheets or an old system takes cleaning, mapping and checking. It is rarely as quick as it looks.
5. Design depth. A clean, consistent interface built from a component library is far quicker than bespoke visual design for every screen.
6. Assurance. Automated tests, accessibility checks, security review and documentation add days, but they are also what keeps the application affordable to change later.

Three worked budgets

To make the arithmetic concrete, here are three typical project shapes. The effort ranges are our own planning assumptions from experience, not industry benchmarks, and every real project should be estimated on its own scope. The day rate used is the IT Jobs Watch full-stack median of £500.

Illustrative development budgets at the £500 median day rate

Project shape	Typical scope	Effort assumption	Development cost
Internal tool replacing spreadsheets	Login, one or two staff roles, forms, search, exports, audit trail	20 to 40 days	£10,000 to £20,000
Customer-facing portal or booking system	Public pages, customer accounts, online payments, confirmation emails, staff dashboard, one or two integrations	40 to 80 days	£20,000 to £40,000
First version of a multi-customer product	Separate accounts per customer, subscriptions, roles and permissions, reporting, onboarding	80 to 160 days	£40,000 to £80,000

Two practical points follow from the table. First, the jump between rows comes from roles, money and integrations rather than from the number of pages. Second, the top of each range is where most projects land when the brief is still vague. A short, paid discovery phase that turns a vague brief into a written scope is usually the cheapest way to move a project towards the bottom of its range.

As one real example of the middle row, the Parents Booking platform we built for schools combines parent bookings, payments, wraparound care and staff reporting. Most of its complexity sits in the rules and reports, not in the screens.

The running costs after launch

A web application is never truly finished. Once it is live, a smaller set of costs arrives every month or every year.

Common running costs for a UK web application (as published on 5 November 2026)

Cost	What it covers	Published figure
Hosting	Running the application and its data	Vercel Pro is listed at $20 a month per developer seat, with a $20 monthly usage credit. Usage beyond the credit is billed separately.
Card payments	Processing customer payments online	Stripe lists 1.5% + 20p for standard UK cards and 2.8% + 20p for premium UK cards, with no setup or monthly fees.
Security certification	Cyber Essentials, often requested by larger customers and public bodies	The NCSC states certification is priced by organisation size, starting at £320 plus VAT.
Maintenance and changes	Security patches, dependency updates, monitoring, small improvements	Mostly people's time. Budget a few hours to a few days a month depending on the size of the application.

Maintenance is the line that most often gets forgotten. Frameworks and libraries release security fixes throughout the year, and some are urgent. Our guide to website and web application maintenance costs works through realistic monthly budgets, and the web application maintenance checklist sets out what a good plan should include.

Five ways to keep the cost under control

• Build the smallest useful version first. Launch the workflow that saves the most time or earns the most money, then add to it with real usage data.
• Buy the commodity parts. Authentication, payments, email delivery and file storage are solved problems. Paying for a reliable service is almost always cheaper than rebuilding it.
• Write the scope down. A one-page list of user roles, key journeys and integrations removes most of the guesswork that inflates quotes.
• Pay for discovery separately. A fixed-price discovery phase gives you a scope, an estimate and a prototype you own, whoever builds the full application.
• Ask about change. Agree up front how new requests are estimated and approved, so the budget does not drift one small change at a time.

Questions to ask every supplier

Put the same questions to each supplier and compare the written answers side by side.

1. Which days of effort are in the quote, broken down by design, development, testing and project management?
2. What day rate is the estimate based on, and is VAT included?
3. Which integrations are included, and what happens if a third-party API does not behave as documented?
4. Who owns the source code, the designs and the hosting accounts at the end?
5. What does support cost after launch, and how quickly are security issues patched?
6. How are changes to the scope estimated and approved?

Getting a realistic number for your project

The fastest route to a reliable figure is a short conversation about your users, your workflow and the systems the application must connect to. With that, a supplier can give you a range you can actually plan around, and tell you which parts carry the most risk.

If you would like that conversation with us, get in touch with a few lines about what you need to build. We will tell you honestly whether bespoke software is the right answer, and if it is, what a sensible first version would cost.