Every prospective client asks some version of this question early, and every honest answer starts with 'it depends'. That's not evasion — a custom web application can reasonably cost anywhere from a few thousand pounds to seven figures, and the gap between those numbers is entirely explained by scope, risk, and how the work is delivered. Rather than quote a single figure that would be meaningless without context, it's more useful to give you a way of estimating where your own project is likely to land.
Start with complexity, not budget
Most custom builds fall into one of three rough bands, and it's worth being honest with yourself about which one you're actually asking for before you go shopping for quotes.
- Simple MVP or internal tool: a handful of core screens, basic authentication, one or two integrations, minimal custom design. Think a booking form with a database behind it, or an internal dashboard replacing a spreadsheet.
- Mid-tier application: multiple user roles, a proper design system, several third-party integrations (payments, CRM, email), moderate custom business logic, and an expectation of ongoing iteration after launch.
- Enterprise-grade or highly regulated build: complex workflows, legacy system integration, strict compliance or security requirements, high availability needs, and a multi-team delivery structure.
Each step up isn't a linear cost increase — it's closer to exponential, because complexity multiplies across design, engineering, testing, and coordination overhead. A project that looks like 'the same app but with two more features' can genuinely double in cost if those features touch permissions, data integrity, or an external system you don't control.
If you're not sure which band you're in, that's normal — it's exactly what a proper discovery phase is for. Treat any quote given before scope is clear as a rough estimate, not a commitment.
Who builds it changes the number as much as what you're building
The same brief can produce very different quotes depending on who delivers it, and the differences aren't just about hourly rate.
- In-house team: highest fixed cost (salaries, recruitment, management overhead, benefits) but the most long-term control and institutional knowledge. Usually only justifiable if software is core to your ongoing operations, not a one-off project.
- Agency or consultancy: a middle ground — you're paying for assembled expertise, project management, and accountability, but without the overhead of permanent hires. Day rates vary significantly by region and specialism, with London-based studios typically commanding a premium over teams based elsewhere in the UK.
- Freelancers: often the cheapest per hour, but you absorb the coordination risk yourself — sourcing, vetting, managing handoffs, and covering gaps if someone becomes unavailable mid-project.
- Offshore or nearshore teams: can lower headline day rates, though the actual saving depends heavily on time zone overlap, communication overhead, and how much oversight you need to add on your side. Treat any specific percentage saving you're quoted with scepticism until you've tested it on a real deliverable.
If you're engaging UK-based contractors rather than an agency or employees, it's worth getting proper advice on IR35 status early — misclassifying a working relationship can create liabilities for the engaging business, and the rules have shifted responsibility in ways that catch out first-time buyers of contractor time. This is a legal and tax question, not something to infer from a blog post, so check current gov.uk guidance or speak to an accountant before you commit to a structure.
Fixed price, time and materials, or discovery-first?
How you commercially structure the engagement affects your risk exposure as much as your final invoice.
- Fixed price: predictable, but only works well when scope is genuinely well-defined upfront. Suppliers price in contingency for the unknowns, so you may pay for risk that never materialises — or get scope quietly narrowed to protect margin.
- Time and materials: more flexible and often better value if requirements will evolve, but it requires trust and active budget management on your side, since there's no natural ceiling without one being agreed separately.
- Discovery-first: a short, paid phase to properly scope the problem before committing to a build price. This costs money upfront but tends to produce far more accurate downstream estimates, because most cost overruns trace back to scope that wasn't understood at the quoting stage.
A supplier who insists on discovery before quoting a fixed build price isn't being difficult — they're usually trying to avoid the two outcomes nobody wants: a lowball quote that falls apart at month three, or an inflated one padded to cover uncertainty you're paying for either way.
The build price is not the total cost
The number most buyers anchor on is the cost to build version one. That's rarely the full picture. Budget conversations should also account for design and UX work before development starts, QA and testing effort (which scales with how much the application matters if it breaks), hosting and infrastructure costs that continue indefinitely, fees for third-party services and integrations, and ongoing maintenance once the application is live — security patches, dependency updates, bug fixes, and small iterative improvements. None of these are optional extras; they're part of owning software rather than buying a one-off product.
The build is the beginning of the cost, not the end of it.
A reasonable rule of thumb, though it varies by project, is to expect ongoing annual maintenance and hosting to represent a meaningful fraction of the original build cost, rather than treating post-launch spend as a rounding error. If a quote you receive doesn't mention what happens after launch, ask — the absence of that conversation is itself informative.
How to actually use this
Instead of asking 'what does a web app cost', try reframing the question for your own project: which complexity band does this realistically sit in, who is best placed to build it given your risk tolerance and internal capacity, which commercial model matches how well-defined your requirements are today, and what's the total cost of ownership over two to three years, not just the invoice for version one. Any supplier worth working with should be willing to walk through that reasoning with you before talking numbers — and should be upfront that early estimates are exactly that, estimates, until scope is properly understood.