What goes into the price of a web application
The decisions that change an estimate, the details that do not and the questions a useful proposal should answer.
Four things move an estimate: the number of distinct screens, the number of integrations, whether the data model is new or already exists, and how much of the content someone else has to write.
What does not move it: the technology name, the number of pages in the proposal, and how the interface is described in adjectives.
Distinct behaviour costs more than page count
Ten pages built from the same content template can be simpler than one operational dashboard. The dashboard may need permissions, filters, state changes, validation and a record of who changed what.
A useful estimate groups screens by behaviour. If two pages display the same content pattern, they belong to one component family. If one page supports several different tasks, each task needs its own estimate.
Integrations carry uncertainty
Connecting a documented API is different from connecting a system that exports a spreadsheet once a day. Both may be called an integration, but the failure modes and testing work are not the same.
The estimate should name each external system, who controls access and what happens when it is unavailable. Unknown access or undocumented behaviour belongs in a discovery stage, not inside a fixed promise.
Data shape affects the whole product
A marketing site mostly publishes content. A client portal stores relationships between people, organisations, orders, files and permissions. Those relationships affect the interface, backend and migration work together.
When the data already exists, we inspect its quality and ownership. When it does not, the team has to define the model before screens can be built reliably.
Content is part of the build
A page cannot be finished around a heading marked “copy later”. Real text changes hierarchy, navigation, component size and the questions the interface must answer.
A proposal should state who writes, approves and enters the content. If the client supplies it, the schedule needs a decision date. If the delivery team writes it, research and review belong in the estimate.
Quality work is visible in the unglamorous parts
Accessibility, responsive behaviour, backups, monitoring and handover rarely appear in a hero mockup. They still decide whether the product can be used and maintained after launch.
Ask which browsers and devices are covered, who owns deployment, how errors are noticed and what your team receives at the end. If the proposal is silent, the work is probably absent or assumed.
What a clear estimate looks like
The estimate should connect each cost to an outcome: a content model editors can use, a payment flow with failure states, an import that can be rerun or a permission system with defined roles.
It should also name the unknowns. A range with clear assumptions is more useful than a precise number built on guesses.
The price becomes easier to judge when every line describes a decision, a behaviour or a deliverable.
