What a Custom Web Application Really Costs in 2026

Ask four agencies to price the same web application and you will get four numbers, and the highest will often be four times the lowest. Buyers read that spread as dishonesty. It almost never is. It is four teams solving four different problems, because the brief did not say which problem it was.

This piece is about closing that gap. Not with a price list — anyone publishing one is quoting a project they have not scoped — but with the variables that actually move the number, so you can tell the difference between a quote that is cheap and a quote that is incomplete.

Why the range is so wide

A web application is not a deliverable, it is a category. The same sentence — we need a portal where our customers can see their orders — covers a two-week read-only view of an existing database and a nine-month multi-tenant platform with roles, permissions, audit logging and a public API.

The estimate follows the interpretation. Cheap quotes are not always the ones cutting corners; sometimes they are the only ones who took the brief literally. Expensive quotes are not always padded; sometimes they are the only ones who noticed you will need single sign-on because you said, in passing, that your ops team lives in Microsoft 365.

The five variables that move the number most

1. How many kinds of user you have

One user type is a build. Three user types with different permissions is a different build, and the jump is not linear. Every role multiplies the screens, the states, the test cases and the edge conditions — what an admin sees when a customer has been deactivated mid-session, who can reverse what, which actions need an audit trail.

The cheapest change you can make to a first release is to cut it to one role and add the others once the core flow has earned its keep.

2. What it has to talk to

Integrations are where estimates go to die, because their cost lives in someone else's system. A modern REST API with sandbox credentials and real documentation is a known quantity. A twelve-year-old ERP with an undocumented SOAP endpoint, no test environment and one person left who understands it is not, and no honest estimate can pretend otherwise.

Before you accept any number, list every system the application must read from or write to, and ask for each one: is there a sandbox, is there documentation, and who owns it internally? Three unknowns on that list is the single most reliable predictor of an overrun. This is exactly the work that sits under API development and third-party integration, and it deserves its own line in the estimate rather than being folded into a feature.

3. The shape of your data

Applications are cheap when data flows one way and expensive when it has to be reconciled. A form that writes a record is simple. Two systems that both believe they own the customer record is a synchronisation problem, and synchronisation problems need conflict rules, retry logic, dead-letter handling and a way for a human to intervene when the automation cannot.

The same applies to history. If you need to know not just what the current state is but what it was on a given date and who changed it, you are building an event log, and that is a design decision with a price rather than a checkbox.

4. How much design the product needs

A tool for forty internal users can ship on a component library and sensible defaults. A product your customers choose to use — or worse, pay for — needs research, flows, prototypes and a design system that will survive the second and third release. That is product design deciding what to build, and interface and experience design deciding how it behaves, and skipping them does not remove the cost so much as move it into rework.

5. The requirements nobody writes down

Non-functional requirements rarely appear in a brief and routinely double a build. Uptime expectations. Response times under load. Data residency. Retention and deletion. Access logs someone will one day be asked to produce. Whether a failed payment can be silently dropped or must be recoverable.

What the bands look like in practice

With those variables in hand, most builds fall into recognisable shapes. These are market observations rather than a price list, and every one of them assumes design, build, testing and deployment rather than code alone.

• An internal tool that replaces a spreadsheet. One role, one or two integrations, no public exposure. Usually weeks rather than months, and the fastest payback in the category.
• A customer portal on top of systems you already run. Two or three roles, authentication, an existing back office to integrate with. Typically a few months, and priced mostly by the integrations rather than the screens.
• A product with paying users. Multi-tenancy, billing, permissions, an audit trail and a support surface. Months rather than weeks, with a meaningful share of the budget in design and QA rather than feature work.
• A platform other systems depend on. Public API, uptime commitments, migration from something already carrying live data. The estimate here is dominated by everything that is not the happy path.

If a quote does not tell you which of these it is pricing, that is the question to ask before you compare it with anything else.

The costs that arrive after launch

The build is a project. The application is a commitment, and the annual cost of keeping one alive surprises teams who budgeted only for delivery.

• Hosting and infrastructure, which scales with usage rather than with your plan for it.
• Dependency and security maintenance, because a framework left untouched for eighteen months is a vulnerability report waiting to be written. This is the substance of proactive maintenance and support.
• Support, which is a rota and an escalation path long before it is a ticketing tool.
• The second release, which is not scope creep. It is the version informed by watching real people use the first one, and a build that does not budget for it ships its assumptions permanently.

A useful planning rule: assume the first year after launch costs a real fraction of the build itself. Teams that budget for it keep improving. Teams that do not spend that year explaining why nothing has changed.

How to brief a quote you can actually compare

You do not need a specification to get comparable numbers. You need five things written down.

1. The one job. What must this application do that nothing you own does today? One sentence, no conjunctions.
2. The user roles. Every kind of person who logs in, and the one thing each of them comes to do.
3. The systems list. Every system it reads from or writes to, with a note on whether documentation and a sandbox exist.
4. The non-functional line. Uptime, data residency, retention, and what an outage actually costs you.
5. The date that matters and why. A trade show, a contract renewal, a licence expiring. Deadlines with a reason behind them get planned around; deadlines without one get negotiated away.

Send the same five points to every firm you are considering. Any two quotes built on that brief are comparing the same project, and the differences between them start meaning something.

The number that matters more than the quote

The most expensive applications we see are not the ones that cost too much to build. They are the ones that were built cheaply, launched into an unclear owner, and quietly abandoned inside a year — where the whole budget was spent and nothing compounds.

So price the outcome, not the artefact. What does the manual process cost you today in hours, errors and lost deals? What does one more year of it cost? Against that, the spread between two quotes is usually the least interesting number in the conversation.

Questions we get asked

Can you give me a ballpark before scoping? We can give you a band and the assumptions behind it, which is more useful than a single number that will move. What we will not do is quote a figure that ignores the integrations list, because that is how a quote becomes a dispute in month three.

Is it cheaper to start with a no-code tool? Frequently, and for a first version it is often the right call — it buys you evidence about what the product needs to be. It becomes expensive at the point where the platform's limits start dictating your business rules, and the migration you delayed is now carrying live data.

Fixed price or time and materials? Fixed price works where the scope is genuinely understood and someone has built the same shape before. Where there is real uncertainty, a fixed price simply moves the argument to the change-request stage. A common middle path is a fixed-price discovery that produces a specification, followed by a fixed price for a build that has actually been designed.

How much should we hold back for changes? Somewhere between 10% and 20% of the build, uncommitted, is a realistic contingency for a project with two or more integrations. Teams that do not hold it end up cutting testing, which is the most expensive saving available.

Does mobile double the cost? A responsive web application does not. A native iOS and Android app is a second product with its own release cycle, review process and support surface, and should be budgeted as one rather than as a feature.

If you are working through this now, our web application development and custom software development teams scope this way as standard — roles, integrations and non-functional requirements first, estimate second.