What a Web Application Really Costs (And Why Quotes Vary 5x)

Three agencies, three quotes, a five-fold difference. Here is what actually drives the price of a web application — and how to read a proposal properly.

You describe the same project to three agencies. One quotes eight thousand, one thirty-five thousand, one a hundred and twenty. All three are being honest. They are simply quoting three different projects, because your brief left enough room for three different interpretations.

The five variables that set the price

1. Number of distinct user roles. An app with one type of user is a fraction of the work of one with an admin, a customer and a partner — permissions, interfaces and edge cases multiply, they do not add.
2. Integrations. Every external system is a negotiation with someone else's API, their rate limits, their sandbox and their outages. Three integrations is often more work than the entire interface.
3. Data complexity. A form that writes a row is trivial. A system where a change in one place must correctly propagate to five others, with history and rollback, is not.
4. Design ambition. A clean interface using a component library is fast. A bespoke, animated, art-directed experience is a separate discipline with its own timeline.
5. Non-functional requirements. Offline mode, multi-language, audit trails, regulatory compliance and high availability can each double the effort while remaining invisible in a demo.

Where the money actually goes

In a typical project, coding features is roughly half of the budget. The rest is discovery and specification, interface design, testing, deployment infrastructure, and the iteration cycle after the first version meets real users. Proposals that allocate ninety percent to development are not cheaper — they are simply omitting the phases that determine whether the thing works.

• 20-25% discovery, specification and design
• 45-55% development and integrations
• 20-30% testing, deployment, post-launch iteration

The cheapest quote and what it usually means

• No discovery phase — the specification will be invented during development, by whoever happens to be typing.
• No testing budget — you become the test team, after launch, in front of your customers.
• A template or page builder presented as custom development, which works until the first requirement it cannot express.
• Fixed price on a vague scope, which guarantees an adversarial relationship the moment reality diverges from the brief.

None of this makes a low quote automatically wrong. For a genuinely simple, well-understood project, a lean approach is the correct choice. It becomes dangerous only when the scope is uncertain — because that uncertainty does not disappear, it just gets billed later.

How to compare proposals honestly

1. Give all three agencies the identical written brief, including your non-functional requirements. Different briefs produce incomparable quotes.
2. Ask each one what they would cut to halve the budget. The answer reveals how well they understand your priorities.
3. Ask what happens after launch: who fixes a production bug at 8pm, under what response time, at what cost.
4. Confirm in writing that you own the code, the data and the accounts. This is non-negotiable and costs nothing to ask.
5. Request one reference for a project of similar complexity — and actually call them.

The approach that keeps budgets sane

Split the engagement. Pay for a short, fixed-price discovery phase that produces a real specification, a data model and a clickable prototype. That artefact is yours, and any agency can quote against it accurately — including the one that produced it. You convert an uncertain hundred-thousand decision into a small, bounded one, and every subsequent quote becomes comparable.

The expensive part of software is rarely the code. It is building the wrong thing correctly.