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

Updated August 24, 2026

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.

What the bands actually look like

Ranges are dangerous in public, because someone always quotes them back at you two years later. Refusing to give any number helps nobody either. At European rates, for a bespoke application rather than a template, the bands look roughly like this. Read them as descriptions of scope, not of quality.

• 8k-25k one role, no integration, component-library design
• 25k-80k several roles, two or three integrations, a real data model
• 80k+ regulatory constraints, high availability, art-directed interface

What moves a project from one band to the next is almost never the number of screens. It is the number of things that must stay consistent with each other. Two roles and one integration sit comfortably in the first band. Add a partner portal, an accounting sync and an audit trail, and the same feature list belongs in the second, because every one of those obligations has to hold true while the other two are changing. It is the same arithmetic we use to scope custom web application work.

The costs that arrive after the invoice

The build price is the part everyone compares. The running cost is the part that decides whether the project was a good idea.

• Hosting and infrastructure, from a few euros a month for a small application to several hundred once you need a managed database, real backups and a staging environment.
• Per-seat subscriptions on everything the app talks to: the CRM, the mail sender, the payment provider, the automation platform. These grow with your headcount, not with your usage.
• Usage fees. Payments, SMS, phone minutes and AI tokens are billed per event, so success makes them bigger, not smaller.
• Monitoring and error tracking, without which you learn about your outages from your customers.
• Dependency updates and security patches. A framework reaches end of life every two to three years, and postponing that migration only makes it larger.
• Support. Someone has to answer the question the interface failed to answer.

Over three years, running costs commonly match or exceed the original build. Ask for that figure before you sign, not after. An agency that has never had to produce it is telling you something about how long its projects usually live.

What actually makes a quote go up mid-project

1. Data migration nobody scoped. The old spreadsheets contradict each other, and cleaning them is a project in its own right.
2. Content that arrives late or never. Text, photographs and legal pages are usually the client's job, and they are usually the reason a launch slips.
3. Decisions waiting on someone who is on holiday. Idle time gets billed, either as delay or as the cost of picking the thread back up.
4. The small report that is not small. A new figure often means new data, captured in a new place, by every screen that feeds it.
5. An integration whose sandbox behaves differently from production, discovered on the day you connect the real account.

Two habits absorb most of this, and the first one starts before the build, with how you choose the agency. Budget ten to fifteen percent for change from the outset, so the first surprise is a decision rather than a negotiation. And hold one short weekly meeting with someone who is actually empowered to decide, because the expensive delays are rarely technical.

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

More on this topic: Growth & Strategy.

Want this built for your business? See what we do.