Web application development cost: what actually moves the number

Why the same brief produces quotes that differ tenfold

Send an identical two-page brief to five development firms and the responses will not cluster. They spread out so widely that at least one buyer, somewhere, concludes the whole industry is making it up.

Some of that is positioning. Most of it is not. A two-page brief does not contain enough information to cost, so each supplier fills the gaps with its own assumptions and then prices those assumptions rather than your brief.

Take a real-shaped example: “a customer portal where our clients can log in and see their account.” Three suppliers can read that sentence and cost three different products. One prices a read-only dashboard over an existing API with a single user type. One prices the same thing plus five roles, an audit trail, downloadable invoices and single sign-on, because “our clients” implies organisations rather than individuals. One notices that account data lives in a fifteen-year-old system with no API, and prices the integration layer everything else depends on.

All three are behaving reasonably. Only one is right about your situation, and the brief does not say which.

So the productive response to a wide spread is not to negotiate the top number down. It is to make the assumptions explicit and re-price against them. Once every supplier is costing the same product, the quotes converge into a much narrower band — and the ones that stay conspicuously low are usually the ones that have not thought about the parts that get expensive later.

The five things that actually drive the cost

Almost everything that moves a web application budget is one of five things. Characterise your project against all five and you can brief accurately, and you can tell a considered proposal from a fast one.

Scope is a count of states, not a count of screens

The most common estimating error, on both sides of the table, is counting screens. A screen is cheap. A state is not.

Every meaningful screen carries conditions that must be designed, built, tested and supported: empty, loading, partial, error, permission-denied, expired session, offline, and “the data is technically valid but absurd.” A list view with filters, sorting, pagination, bulk actions and an export is not one screen; it is one screen and roughly a dozen behaviours, each of which can be got wrong in a way a user will notice.

A useful trick when writing a brief: count the verbs, not the nouns. “Users can approve, reject, delegate, comment on and export requests” is five capabilities, each with a permission question, an audit implication and a failure mode. “A requests page” is one noun, and it is why your quotes came back tenfold apart. Because every state is a design decision before it is a build decision, UI/UX design work that resolves states early tends to reduce total cost rather than add to it.

Integrations are contracts with someone else’s uptime

An API integration reads as one line in a brief and behaves like a subproject. Each brings authentication, a data model that does not match yours, rate limits, a sandbox that behaves differently from production, error handling for when the other system is down, and a maintenance obligation for when the vendor changes their API version.

The cost varies by what you are integrating with. Cheapest: a well-documented, versioned REST or GraphQL API with a real sandbox, webhooks and a published deprecation policy. Middling: a mature SaaS product with an SDK but idiosyncratic data semantics — most CRMs, most payment providers. Expensive: a legacy system reached over SFTP with a nightly CSV, an on-premise database behind a VPN, or a vendor whose “API” is an undocumented endpoint mentioned in a support email.

For each integration, answer four questions before asking anyone to quote: who owns the credentials, is there a sandbox, what does the user see when it fails, and does data flow one way or both? Two-way synchronisation is a materially harder problem than reading, because it introduces conflict resolution — and conflict resolution is where integration budgets actually go.

Roles, permissions and multi-tenancy

A second user type does not add a second set of screens. It adds a permission question to every screen that already exists, and a test case for every combination of role and action. Three roles with genuinely different capabilities make a substantially larger application than one role, even though the screen count barely moves.

Multi-tenancy is the version of this that surprises people most. “Each client sees only their own data” sounds like a filter. In practice it is an architectural decision reaching into the data model, the query layer, the caching strategy, background jobs, exports and the entire test suite — because the failure mode is one tenant seeing another’s data, and that is not recoverable by apology. Broken access control sits at the top of the OWASP Top 10:2025 list of critical web application risks. If your application is multi-tenant, say so on the first page of the brief.

Compliance turns judgement calls into requirements

Non-functional requirements are the part of the brief nobody writes and everybody pays for. They are also where “we will sort it later” is most expensive, because retrofitting is genuinely harder than building in.

Security posture. There is a large gap between “we followed sensible practice” and “we can evidence conformance.” The OWASP Application Security Verification Standard exists so this can be specified in a contract rather than argued about afterwards; naming a verification level is one of the most useful sentences you can put in a brief.

Audit regimes. SOC 2 and HIPAA are not features. They are evidence regimes imposing logging, access control, retention, key management and vendor review obligations that touch the whole system. Deciding you want them after launch is a rebuild in slow motion.

Accessibility. WCAG 2.2 at AA is the working standard and increasingly a legal requirement rather than a preference — the European Accessibility Act brings e-commerce, banking services and e-books into scope across the EU. Building to AA from the start costs a fraction of remediating a finished application, because most failures are systemic rather than per-page.

The GOV.UK Service Standard is a useful borrowed checklist even outside the public sector. Its fourteen points — among them making sure everyone can use the service, protecting users’ privacy and operating a reliable service — are a decent proxy for what a serious application has to satisfy.

Post-launch is not a rounding error

The build is the first instalment, not the purchase. Ongoing costs include hosting that scales with usage, dependency updates that stop being optional once you hold user data, monitoring, a support arrangement, and the change budget.

An application generating no change requests is usually one nobody is using. If it works, people want it to do more, and the cost of that depends on how well the first version was built. That is what technical debt means in budget terms: not ugly code, but a rising cost per change. Ask any supplier to quote year two alongside year one — the gap between suppliers on that question is often more informative than the build number.

Three scope tiers, and how to tell which one you are in

Most projects sit recognisably in one of three tiers. The tiers do not correspond to prices; they correspond to what dominates the effort, which is what you actually need to know.

	Tier 1: internal tools and MVPs	Tier 2: business applications	Tier 3: multi-tenant SaaS and regulated platforms
Shape	One workflow, one team, users who can be trained	Several connected workflows, external users, real operational dependence	A product other organisations buy, or an application under an audit regime
Roles	One or two, informally enforced	Three to six, formally enforced, plus an admin surface	Role hierarchies per tenant, plus your own support and billing roles
Integrations	Zero to one, usually read-only	Two to five, at least one two-way	Identity, billing, export, plus customer-specific connectors
Where cost concentrates	Getting to something usable at all	States, permissions, integrations, data quality	Isolation, non-functional requirements, operations, evidence
Dominant risk	Building the wrong thing quickly	Underestimating states and edge cases	Isolation failure, compliance rework, operational load
Spend here first	Discovery and a throwaway prototype	Data model and permission model	Architecture, security specification, deployment pipeline

The tier matters more than the feature list, because it determines where the money goes regardless of what the brief says. A Tier 3 project with a Tier 1 budget does not become cheaper. It becomes a Tier 3 project delivered badly.

What the day rate hides

Comparing suppliers on day rate is the second most common procurement mistake, after comparing headline totals. A rate is a price per unit of something you have not defined, and two suppliers quoting the same rate can deliver an order-of-magnitude difference in what an hour contains.

Discovery, which is not a sales phase

The GOV.UK Service Manual is blunt about the purpose: “Before you commit to building a service, you need to understand the problem that needs to be solved,” and “You should not start building your service in discovery.” It also says something most commercial suppliers will not: “It’s not a failure to stop at the end of the discovery phase if your research shows that’s the best thing to do.”

That is the test of whether a discovery phase is real. If the only possible outcome is a proposal to build, it was a sales process with a day rate attached. A genuine discovery can conclude that the problem is better solved by configuring something you already own, by fixing a process, or not at all.

QA, and the gap between testing and test automation

Manual testing before each release is a cost that recurs forever and degrades as the application grows. Automated tests are a cost paid once per behaviour that makes every subsequent release cheaper. Low quotes are often achieved by quoting the first and describing it as the second. Ask not “do you test?” but: what proportion of critical paths are covered by automated tests, do they run on every change, and will they be handed over in a state our next developer can run?

DevOps, environments and the cost of shipping

An application needs somewhere to run, somewhere to be tested before it runs, a repeatable way to get between them, and a way back if it goes wrong. DORA’s research measures exactly this, and its metrics — deployment frequency, change lead time, change failure rate and failed deployment recovery time — are a reasonable shorthand for asking how a supplier’s delivery actually works. The finding worth carrying into a procurement conversation is that speed and stability are not a trade-off: teams that deploy frequently also tend to break things less. A supplier who treats deployment as a risky manual event is telling you something about the next five years.

Handover and the exit

The cost felt most sharply is the cost of leaving. Ask in writing what you receive at the end: repository ownership, infrastructure defined as code rather than clicked into a console, documented environment variables, a runbook for the things that break, and a process for onboarding a developer who has never seen the codebase.

Fixed price, time and materials, or capped sprints

The commercial model does not change how much work there is. It changes who carries the risk of being wrong about how much work there is, and that has second-order effects on behaviour.

	Fixed price	Time and materials	Capped sprints
Who carries scope risk	The supplier	You	Shared, with a ceiling
Effect on behaviour	Defends the scope line; every discovery becomes a change request	Encourages exploration, and drift if nobody governs it	Forces prioritisation, because the ceiling forces trade-offs
Works when	Scope is genuinely knowable: a defined integration, a rebuild, a bounded phase	You have product capability in-house and steer weekly	You need flexibility but also a number for a board
Fails when	The brief is exploratory: you pay an invisible contingency, then pay again for changes	Nobody owns priorities and the burn outlives the enthusiasm	The cap is treated as a target rather than a limit
Insist on	A written assumption register and an agreed change process	A weekly burn report and a backlog you control	A defined cadence, a visible backlog, a real break clause

A pattern worth knowing: fixed price for discovery and for clearly bounded phases, capped sprints for the build. You get a firm number for the part that can be specified, and keep the ability to change your mind about the part that cannot — which is usually the part that matters. Whatever the model, the break clause is the term to read most carefully. The right to stop after a phase with everything built to date in your possession is the strongest protection a buyer has, and it costs nothing to negotiate at the start.

Where AI-assisted development does and does not reduce cost

This deserves plain treatment, because it is currently the largest unexamined assumption in software budgeting.

AI coding assistants are genuinely useful. They are fastest at scaffolding, boilerplate, test fixtures, unfamiliar syntax, and first drafts of things written a thousand times before. On greenfield work of a familiar kind the acceleration is real.

The evidence that they reduce the cost of serious application work is weaker than the discourse suggests. A randomised controlled trial run by METR in early 2025 took sixteen experienced open-source developers working on 246 real issues in repositories they knew well and found that, when AI tools were allowed, they took 19% longer. The developers had expected a 24% speedup beforehand and still believed afterwards they had been sped up by 20%. That gap between measured and perceived effect is the finding that should inform your budget, because it means self-reported productivity gains are not evidence. DORA’s 2024 research points the same way from another angle: AI adoption raised individual productivity, flow and job satisfaction while negatively affecting delivery throughput and stability. More code, arriving faster, into systems whose review and testing capacity did not grow.

The practical reading for a buyer: do not accept a discount justified by AI tooling unless the supplier can show what changed in their delivery process rather than their editor; expect review to become the constraint; and note that the parts AI does not help with are the expensive parts — deciding what to build, modelling the domain, resolving conflicting stakeholder requirements, and integrating with a system nobody documented. Where AI does reliably save money is the surrounding work: documentation, test generation, log analysis, and the analytics and reporting layer that usually gets cut for time.

How to cut cost without cutting the wrong things

If the number comes back above the budget, there are good cuts and bad cuts, and they are not hard to tell apart.

Cut these first, with a clear conscience:

1. User types. Ship for the one role that matters and handle the others manually. The largest lever available.
2. Configurability. Hard-code the thing that has one value today; settings screens are built for a flexibility nobody exercises.
3. Reporting. Export the data and let people use a spreadsheet until you know which numbers they look at.
4. Non-critical integrations. A CSV upload now, an API integration once the workflow has proved itself.
5. Bespoke anything with a good off-the-shelf equivalent. Authentication, payments, email delivery, file storage, search.
6. Breadth of workflow. One workflow done properly beats four done partially, and produces evidence you can use to fund the rest.

Do not cut these, whatever the pressure:

1. The data model. Cheapest to get right at the start, most expensive to change later, and everything sits on it.
2. The permission model. Retrofitting authorisation into an application that assumed one role touches every query.
3. Automated tests on critical paths. Cutting them defers the cost into every future release and makes each one riskier.
4. Accessibility. Systemic failures are cheap to prevent, expensive to remediate, and increasingly a compliance exposure.
5. The deployment pipeline. A project that cannot be deployed repeatably consumes the saving within a year.
6. Discovery, if you do not already know the answer. The most expensive software is software built efficiently that should not have been built at all.

Cut breadth, never cut foundations. Features can be added later at roughly the cost of the feature. Foundations cannot.

One brief, three legitimate quotes

Here is what the spread looks like when nobody is behaving badly. A distributor asks for “a portal where our trade customers can place repeat orders and see their invoices.”

The low quote assumes an authenticated front end over the existing ERP’s API: customers see their order history, reorder from it, and download invoice PDFs the ERP already generates. One role, no admin interface. Sensible and deliverable — and dependent on the ERP’s API doing all of that, which nobody has verified.

The middle quote adds multiple users per trade account with different permissions, because trade accounts are organisations; an approval step, because the buyer and the approver are different people; and an admin view, because the sales team will need to see what a confused customer is seeing. It also budgets for the ERP’s API being insufficient and includes a spike to find out.

The high quote notices two things the brief did not say. “See their invoices” means financial data, so an audit trail and a retention policy. And the distributor sells into the EU, which puts the ordering journey within reach of accessibility legislation, making WCAG 2.2 AA a requirement rather than a preference. It also prices a data migration, because customer records in the ERP are duplicated.

All three suppliers are competent. The differences are entirely assumptions, and only the client can resolve them. Ask each supplier to price the union of all three assumption sets and the numbers move much closer together. Our note on the questions to ask a web development agency covers that conversation; if you have not settled on a delivery model, the trade-offs between an agency, a freelancer and an in-house team come before the cost question rather than after it.

Turning an estimate into something you can fund

An estimate is not a plan. To take a number to whoever signs it off, you need four things beyond the figure.

1. A written assumption register. Every assumption the supplier made, numbered, with the cost impact of each being wrong. Most suppliers will produce one if asked.
2. A phase boundary with a decision at it. Something that can be shown, used and evaluated before the rest of the budget is committed, with a genuine option to stop.
3. A total cost of ownership line, not just a build line. Hosting, licences, support and an annual change allowance. Present the three-year figure; you will be asked for it eventually.
4. A named owner on your side. Someone with authority to decide at the pace the project needs. Every project that overruns has a decision queue in it, and the queue is usually on the client side.

Do that and the conversation stops being about whether the number is too big and starts being about whether the scope is the right scope, which is the only version that has ever saved anyone money.

If you would like a second opinion on a proposal you already have, our web application development and web development practices do this kind of work — and we would rather tell you the project is smaller than you think than sell you the version that is not.