What does a custom web application cost?

An honest answer to this question begins with a counter-question. This text names the factors that drive effort, explains them using two assumed project scopes, and says which details make a reliable estimate possible. We deliberately do not name prices here — a figure without your scope would be a guess.

Who it is forManagement, purchasing, project leads
LevelPurchase preparation
Reading timeabout 8 minutes
Last updated16 October 2026

What you will learn

Which six factors determine the effort
Why two applications with the same number of screens cost different amounts
Which items are added after launch
Which details we need for a reliable estimate

Why there is no figure here

Online you will find price ranges for "a web application". They are not wrong, but say little without a scope: they give an order of magnitude, but do not replace an estimate for your process.: The range runs from a single screen with a list to a portal with approvals, interfaces and data migration. Both are called a web application.

A figure we named here would therefore not be a quote, but an expectation we would have to correct later. Instead, we explain what makes the difference — so that you can compare quotes, ours included.

Six factors that drive effort

Business rules. What counts is not the number of fields, but the number of decisions the software has to make — and the exceptions to them.
Roles and permissions. An application for one group is something different from one for five groups with different views of the same data.
Interfaces. Every connection to another system brings authentication, format differences, error handling and testing with it.
Data migration. Existing data is rarely as clean as it sounds in conversation. Checking, cleaning and transferring it is work in its own right.
Operational requirements. How bad is an outage of one hour? The answer determines backups, monitoring and effort.
Stakeholders and decision paths. The more parties have to agree, the longer the project takes — not the implementation.

Two assumed scopes compared

The following two scopes are invented examples for illustration. They show why the number of screens is a poor yardstick.

Scope 1 · assumed example

One entry screen, one list, one report
Five to ten users, one role
No connection to other systems
No data migration from a legacy system

Scope 2 · assumed example

Several screens with approval steps
Several roles with different permissions
Two interfaces to existing systems
Migration of existing data, documents, logs

Both scopes are assumed examples for illustration, not quotes. The difference lies not in the number of screens, but in permissions, interfaces and data migration.

The second scope does not have twice as many screens, but significantly more decisions: Who may approve a step? What happens in case of absence? What if the interface rejects it? Which legacy data comes along, and which does not? These questions are the effort — not the interface.

An example from practice

The change that was bigger than expected

A mandatory field is to be added to an application: a cost centre on the order. The effort in the screen is small. Then the real questions arise: What happens to the three thousand orders that do not yet have a cost centre? Does it appear in the handover to accounting? May every role change it? Do old reports remain comparable?

That is why "one more field" is not a reliable description of effort. Anyone asked to estimate effort has to ask about the existing data, the handover and the permissions — not about the field.

What is added after launch

These items belong in every plan, even though they are often missing from the first quote:

Operation: servers, backups, monitoring, updates.
Maintenance of the technical foundation: PHP versions and libraries keep evolving, even though your requirements do not change.
Changes arising from operation: what comes up in daily use is usually sensible — and work.
Support for users, especially in the first weeks.

A quote that does not mention these points is not cheaper. It is merely less complete.

What makes a reliable estimate possible

We do not need a requirements specification. What helps:

A description of the process in your own words, step by step.
The systems involved — spreadsheets and mailboxes count too.
Who works with the software and who makes which decisions.
What is to happen to the existing data.
How you would recognise after six months that the application has paid off.

With these details, a scope can be defined and an effort estimated. If one of them is missing, we estimate the uncertainty as well — and state it, rather than packing it into a smooth figure.

Common misconceptions

Not without a scope. A ballpark figure that later has to double helps nobody — it damages the collaboration before it begins.

A fixed price presupposes a fixed scope. It is right where the scope is clearly described, and becomes expensive where questions still have to be clarified during the work — the risk is then priced in.

No. An estimate states the expected effort under named assumptions. If the assumptions change, the effort changes; that should be said openly, not concealed.

About the author

Fabian Lücker is managing partner of PHP-Schmiede KG in Rheine and has worked in software development since 2007. He is responsible for development and design and writes here about decisions that arise in real projects.

Questions about the article? Write to us

Define the scope, then estimate

Describe your task and the systems involved. You will receive an assessment with stated assumptions.

Submit a development enquiry