How to Estimate a Web App Project: UK Cost Factors

"How much will it cost to build our web app?" It's the first question every founder and product owner asks, and the hardest to answer honestly. Anyone who gives you a firm number in a 30-minute call is either guessing or selling. Accurate estimation is a process, not a price list.

This guide explains what actually drives web app project estimates in the UK, why fixed quotes so often fail, and how to brief a development company so the estimate you get is one you can trust.

Why web app estimates vary so wildly

Ask five UK agencies to quote the same "simple booking platform" and you'll get figures ranging from £15,000 to £150,000. That isn't evidence that four of them are dishonest — it's evidence that "simple booking platform" describes at least ten different products.

Does "booking" mean picking a time slot from a calendar, or does it mean resource scheduling across 40 staff, with buffer times, cancellation policies, payment capture, refunds, SMS reminders, calendar sync, and a customer portal? The first is a few weeks of work. The second is a few months. Both get described as "simple" in initial briefs.

The variation comes from assumptions. Every estimate is built on dozens of them: how many user roles, how complex the permissions, whether you need an admin panel, what integrations are involved, how much design is custom, what happens when things go wrong (error states, edge cases, failed payments). A low quote usually means fewer assumptions were questioned, not that the work is cheaper.

The real cost drivers

Strip away the sales language and these are the factors that move the number:

• Scope depth, not feature count. Ten shallow features cost less than three deep ones. A "user profiles" feature can mean a name and avatar, or it can mean verification, document upload, approval workflows and audit trails. Depth is where estimates live or die.
• Number of user roles and permission levels. Every additional role (admin, manager, customer, partner) multiplies the surfaces you build and test. A single-role app and a four-role platform are different projects wearing similar descriptions.
• Integrations. Each third-party integration — payments (Stripe, GoCardless), CRMs, accounting software, SMS providers, mapping — adds development time, testing time and ongoing maintenance liability. "Just connect it to our CRM" is never just anything.
• Custom design vs. component libraries. A bespoke, branded interface designed from scratch costs significantly more than one built on a design system or component library. Both are legitimate choices; the estimate should reflect which one you're buying.
• Data complexity. Apps that are mostly forms and listings are cheaper than apps with complex data relationships, reporting, search, or real-time features. A dashboard with five custom reports is a project inside your project.
• Compliance and security. Handling payments (PCI considerations), health data, or children's data adds security work, audits and legal review. GDPR compliance alone — proper consent, data export, deletion workflows — is real, billable work that cheap quotes silently omit.
• Platforms. A responsive web app is one codebase. Add native iOS and Android apps and you've roughly doubled or tripled the build. Many "web app" briefs quietly include mobile apps by the second meeting.
• Content and data migration. Moving 10,000 existing records, cleaning them, and mapping them into a new system is unglamorous work that takes weeks and gets forgotten in every initial estimate.

UK market ranges: what things actually cost

Broad market ranges, not quotes — treat these as orientation, because every project differs:

• MVP / proof of concept: £15,000–£40,000. A focused product proving one core workflow, built to be thrown away or rebuilt.
• Small business web app: £30,000–£80,000. Customer portal, booking system, or internal tool with a handful of integrations.
• Mid-size platform: £80,000–£200,000. Multiple user roles, custom workflows, several integrations, proper admin tooling.
• Complex / enterprise: £200,000+. High security, high scale, deep integrations, regulatory requirements.

Day rates for UK development agencies typically run £400–£900 per developer per day depending on region, seniority and specialism — London at the top end, the North and Midlands more competitive. Freelancers run lower; large consultancies run higher. Anyone quoting far outside these bands is either cutting corners or padding.

Why fixed quotes fail

Fixed-price quotes fail for a structural reason: at the point you ask for the quote, you know the least about the project that you will ever know. Requirements are vaguest at the start and clearest at the end — but fixed pricing locks the price at the start.

What happens next is predictable. Either the agency absorbs the gap (and cuts corners to survive — fewer tests, skipped edge cases, rushed code), or every change becomes a variation order fought over line by line, and the relationship turns adversarial. Fixed price doesn't remove risk; it just decides who suffers when reality arrives.

Fixed pricing can work when scope is genuinely fixed: a well-defined, small project with no unknowns and no integrations. For anything involving discovery, user feedback, or third-party systems, it's the wrong tool. See our deeper comparison of fixed price vs time and materials for the full breakdown.

The models that work better for real web apps:

• Time and materials with a capped budget. You pay for actual work, with a ceiling and regular check-ins. Honest, flexible, and the industry standard for a reason.
• Phased fixed pricing. Fix the price per phase (discovery, MVP, iteration), not for the whole project. Each phase's quote is informed by the last phase's learning.
• Discovery-first. Pay for a 2–4 week discovery phase (£5,000–£15,000 typically) that produces wireframes, a technical architecture, and a proper estimate. Then decide whether to build, and with whom. This is the cheapest insurance in software.

How to brief so the estimate is trustworthy

The quality of the estimate you receive is capped by the quality of the brief you send. A good brief doesn't need to be long — it needs to be specific:

1. Start with the problem, not the features. "Our support team spends 15 hours a week on manual onboarding" produces better estimates than "we need a dashboard". Good developers estimate solutions to problems; feature lists without context get padded because the agency can't tell what matters.
2. Define your users. Who uses this, and what does each type of user need to do? Even a rough list of roles transforms an estimate.
3. Describe the must-have workflow. Walk through the single most important journey step by step: "A customer lands here, does this, then this happens." One detailed workflow beats ten bullet-pointed features.
4. List your integrations and systems. Name the actual tools: "Stripe for payments, HubSpot CRM, Xero for invoicing." Each named integration can be estimated; each unnamed one becomes a contingency.
5. State your non-negotiables. Deadline, budget ceiling, compliance requirements, must-support browsers or devices. Constraints improve estimates because they bound the solution space.
6. Say what you're NOT building. "No mobile app in phase one. No multi-language. Admin panel can be basic." Exclusions prevent the agency from estimating the deluxe version.
7. Share your budget range. This feels like showing your cards, but it isn't — it lets the agency scope honestly to what you can afford instead of quoting a fantasy and negotiating down. A good agency will tell you what your budget actually buys.

Red flags in the estimates you receive

When quotes come back, watch for:

• The suspiciously cheap quote. 40% below everyone else isn't a bargain; it's a misunderstanding of the scope or a plan to recover margin through variations later.
• No questions asked. An agency that quotes without asking a single clarifying question didn't estimate your project — they estimated a generic one.
• No breakdown. A single number with no phasing, no assumptions list and no exclusions is not an estimate; it's a guess with confidence.
• "Unlimited revisions" or "everything included". Nothing is unlimited. This is sales language covering an undefined scope, and it ends in disputes.
• No mention of testing, deployment or handover. If QA, hosting setup, documentation and training aren't in the estimate, they're either missing (you'll pay later) or being skipped (you'll pay forever).

Estimation is the first test of a development partner. The agency that asks hard questions, challenges your assumptions and gives you a phased, caveated estimate is the one that will tell you the truth during the build. The one that nods and gives you a tidy number is telling you what you want to hear.

If you're scoping a web application, our application development team starts every project with a structured discovery — so the estimate you get is built on understanding, not guesswork. It's also worth reading our guide on custom vs off-the-shelf software before you commit to building anything. To talk through your project, contact us with whatever you've got — even a rough idea is enough to start the conversation properly.

FAQs

How much does it cost to build a web app in the UK?

As a broad market range: £15,000–£40,000 for an MVP, £30,000–£80,000 for a small business web app, £80,000–£200,000 for a mid-size platform, and £200,000+ for complex or enterprise builds. The honest answer for any specific project requires a proper brief and ideally a discovery phase — anyone quoting precisely without one is guessing.

Why do web app quotes vary so much between agencies?

Because every estimate is built on assumptions, and vague briefs force agencies to guess. A low quote usually means fewer assumptions were questioned, not that the work is genuinely cheaper. Compare the assumptions lists and exclusions behind the numbers, not just the numbers themselves.

Is fixed-price or time-and-materials better for a web app?

For anything beyond a small, fully-defined project, time and materials (ideally with a budget cap) or phased fixed pricing works better. Fixed pricing for the whole project locks the price when you know the least about the requirements, which leads to corner-cutting or adversarial variation orders. See our full comparison of fixed price vs time and materials.

What should I include in a brief to get an accurate estimate?

The problem you're solving, your user roles, the key workflow described step by step, your integrations (named specifically), your non-negotiables (deadline, budget, compliance), and what you're explicitly not building. Share your budget range — it lets agencies scope honestly instead of quoting a fantasy.

How long does it take to build a web app?

A focused MVP typically takes 8–16 weeks. Small business apps run 3–6 months; mid-size platforms 6–12 months. Anything promising a complex platform in "a few weeks" is either underestimating dramatically or planning to deliver something far simpler than you imagined.