What Determines Web Software Cost? A Scope and Budget Guide

Web software cost is shaped less by a page or screen count than by the business process, roles, rules, data, integrations, quality conditions and post-launch responsibilities involved. Two portals may look similar while requiring very different work: one may have a single role and manual data entry; the other may need granular permissions, an ERP connection, data migration and records of critical actions.

A number provided before those needs are understood is normally an initial estimate based on assumptions, not a final price. A useful proposal should make three things visible:

1. Which outcome and deliverables are included?
2. Which assumptions, dependencies and exclusions apply?
3. How will change, operations and post-launch costs be managed?

This guide does not provide market rates or a Kumsal Ajans price list. Project scope, team, commercial model and timing vary. It provides a framework for understanding what a proposal purchases and which components belong in the total budget.

Ten factors that determine web software cost

1. Discovery and requirements uncertainty

“We need a dealer portal” or “we want to digitise this process” begins a conversation but does not define a quote. When users, journeys, rules and integrations are unknown, the team must first perform discovery and analysis.

Discovery may cover:

• business goals and success measures,
• current process and problems,
• user or stakeholder interviews,
• roles and permissions,
• core journeys,
• data and legacy-system review,
• integration feasibility,
• first-release prioritisation,
• technical risks and dependencies,
• requirements and acceptance criteria.

If a fixed development price is requested under high uncertainty, the provider may price the risk or limit the offer through narrow assumptions. A separate, bounded discovery phase can define the scope before producing a more reliable delivery plan.

2. Roles and permission model

The existence of a sign-in screen says little about complexity. Analysis, interface, engineering and testing expand when customers, dealers, employees, administrators, finance, operations and support roles see different data or perform different actions.

Cost-driving questions include:

• How are users registered or invited?
• Can one person belong to several organisations or roles?
• Are permissions applied to pages, actions, fields or individual records?
• Are approval and delegation flows required?
• Must critical actions be recorded?
• Who provisions and removes access?

“Administration panel included” does not answer these questions. Define the job each role performs in every module.

3. Workflows and business rules

Saving form data is not equivalent to managing an order, application, reservation or approval process. Status transitions, calculations, limits, pricing priorities, notifications, cancellations and exceptions affect engineering and testing effort.

A request workflow may contain separate work for:

• request creation,
• required-field and business-rule checks,
• routing to the authorised person,
• approval or rejection,
• change history,
• user notification,
• transfer to an external system,
• reprocessing failed transfers,
• reporting and export.

The proposal should show the end-to-end scenarios and important exceptions beneath each module name.

4. UX/UI and design scope

Adapting an established design system is different from creating a brand-specific interface language and complex transaction experience.

Design cost drivers include:

• user research and journey design,
• information architecture,
• wireframes and prototypes,
• original visual direction,
• component and design system,
• desktop, tablet and mobile behaviour,
• density of tables, filters, charts and forms,
• interfaces for different roles,
• accessibility requirements,
• content, empty states, errors and help text,
• approval stages and revision boundaries.

Screen count is not a sufficient measure. Ten similar list screens may need less design and testing than one complex planning or data-visualisation interface.

5. Integrations and third-party services

An ERP, CRM, payment, shipping, mapping, identity, email, messaging or accounting integration adds more than an “API connection.” The readiness of the connected system and required failure behaviour matter.

For each integration, identify:

• data direction and field mapping,
• real-time or scheduled operation,
• authentication and access,
• test environment and sample data,
• transaction and usage limits,
• timeout, retry and duplicate prevention,
• error recording and notification,
• maintenance responsibility after third-party changes,
• licence, transaction or subscription charges.

Missing documentation, a changing legacy system or poor data quality adds discovery and delivery risk. The proposal should distinguish third-party charges included by the provider from charges paid directly by the client.

6. Data model, migration and cleansing

Creating the new application’s data structure, moving legacy data and correcting that data are different tasks.

Data scope may include:

• entities and fields,
• relationships and history,
• import and export,
• legacy mapping,
• missing or duplicate-record cleansing,
• file and media transfer,
• personal or sensitive-data classification,
• retention and deletion rules,
• migration rehearsals and reconciliation,
• data freeze or parallel running during transition.

“Migration included” remains ambiguous unless it states the source, volume, format, cleansing ownership and number of migration runs.

7. Technical architecture and infrastructure

Expected usage, criticality and integrations influence architecture. A small internal tool and a high-transaction system whose outage stops operations need different foundations.

Assess:

• usage and traffic assumptions,
• data and file volume,
• scaling approach,
• development, test, staging and production environments,
• server or cloud services,
• domain, TLS and network configuration,
• error and performance monitoring,
• backup and recovery,
• release automation,
• third-party components and licences,
• technical documentation and handover.

Separate infrastructure costs from initial development. Recurring and usage-based services and their management responsibility should appear independently.

8. Security, accessibility and quality verification

Security and testing are not optional extras added after development; the required depth depends on application risk. The NIST Secure Software Development Framework recommends keeping security requirements known and considering them throughout software development (NIST SSDF SP 800-218).

Budget components may include:

• security requirements and threat assessment,
• role and permission checks,
• code and dependency checks,
• functional and integration tests,
• browser and device tests,
• accessibility design and verification,
• performance and load tests,
• user-acceptance support,
• independent security assessment or penetration test,
• remediation and retesting.

Not every project needs every test type at the same depth. The proposal should name the included quality work, environment, owner and acceptance condition.

9. Release, training and handover

Completed code is not automatically a ready production service. Release work may include:

• production setup,
• migration and final synchronisation,
• domain, DNS and TLS work,
• user and permission setup,
• basic analytics and event measurement,
• pre-release checks,
• rollback planning,
• administrator or user training,
• user and technical documentation,
• source code, data, account and access handover,
• a period of close post-launch observation.

Ownership between client and provider should be written into the proposal.

10. Maintenance, support and new development

Browsers, operating environments, dependencies, services and business needs change after release. The initial development price should not be assumed to include maintenance, support and unlimited new features.

Separate:

• Defect correction: Approved scope does not behave as agreed.
• Maintenance/operations: Updates, monitoring, backups, service continuity and routine technical work.
• New development: A new feature, role, integration, design or changed rule.

Support hours, response targets, critical-incident definition, included effort and additional-development pricing should be visible in the contract.

Plan the budget in seven sections

Use a common breakdown when comparing proposals:

Mark each line as included, excluded, client-owned, third-party charge or priced after discovery.

Fixed price, time and materials, and phased delivery

Fixed scope and fixed price

This model can work when deliverables, acceptance criteria, dependencies and the change process are sufficiently clear. It creates budget predictability but does not mean unknown work is silently included.

Check:

• scope and exclusions,
• client responsibilities,
• assumptions,
• revision and approval boundaries,
• change-request pricing,
• effect of delayed content, access or approval.

Time and materials

This model can provide flexibility when needs evolve through learning or technical uncertainty is high. It still requires a visible backlog, regular reporting, a priority owner and a budget boundary.

Ask about:

• role- or team-based charging,
• shared time records,
• estimate-to-actual reporting,
• monthly or sprint budget cap,
• prioritisation and stop decisions,
• acceptance of completed work.

Phased or hybrid model

Discovery can be a bounded fixed engagement; the MVP can then use fixed scope or controlled time and materials. Later releases follow usage evidence. This creates decision points instead of claiming early certainty for the whole investment.

No commercial model is automatically cheapest or safest. Suitability depends on scope maturity, frequency of change, decision capacity and allocation of risk.

Why the lowest proposal may not have the lowest total cost

A price difference can represent a different rate or a different scope. A lower proposal may exclude:

• requirements analysis,
• custom design or mobile detail,
• migration and cleansing,
• integration failure scenarios,
• security and accessibility verification,
• realistic test-data preparation,
• training and documentation,
• source-code or account handover,
• post-launch support,
• third-party licences and usage charges.

Compare proposals through a deliverable-scope-assumption matrix, not the total alone. Different offers cannot be compared reliably as if they buy the same work.

Evaluate total cost of ownership

Initial development is one part of the product life cycle. The US Government Accountability Office cost-estimating guide lists defining the estimate’s purpose, including life-cycle costs, documenting assumptions, and analysing risk and uncertainty among the practices supporting a credible estimate (GAO Cost Estimating and Assessment Guide). This is not a Kumsal Ajans pricing rule; it is a general planning principle used here to expose budget components.

Recurring and future items may include:

• server or cloud usage and traffic,
• domain, TLS, email and storage,
• third-party licences and transaction charges,
• monitoring and backups,
• security and dependency updates,
• support and incident response,
• content or management operations,
• adaptation to new browsers, devices or services,
• new modules and integrations,
• export, handover or migration to another system.

A three- or five-year table can compare options over the same period; it is not an SEO or financial rule. When future amounts are uncertain, record the assumption, pricing mechanism and usage unit.

Show uncertainty and risk in the budget

Classify uncertainty instead of hiding it:

• validated scope,
• assumption-based scope,
• third-party dependency,
• technical research required,
• awaiting client data or access,
• excluded.

For each item, record possible impact, validation step, owner and decision date. Rather than adding a universal contingency percentage, resolve the unknown or show scenario-based variation.

Example scenarios:

• Baseline: API and data verified; defined MVP journeys.
• Conditional: Legacy cleansing or an additional permission rule is required.
• Expanded: New integration, high volume or independent security testing is added.

Information to prepare before requesting a proposal

• business goal and primary user outcome,
• user groups and roles,
• core journeys and important exceptions,
• first release and exclusions,
• current systems and data sources,
• integrations and access status,
• content, design and brand materials,
• expected usage and data volume,
• security, accessibility and compliance needs,
• target date and external dependencies,
• test and acceptance owner,
• release, training, handover, maintenance and support expectations,
• budget range or investment boundary when the organisation can share one.

If scope is unclear, prepare the web software requirements document and MVP decision before comparing delivery proposals.

Web software proposal checklist

Before accepting a proposal, answer:

• Are the target outcome and first release clear?
• Are workflows defined beneath module names?
• Are roles and permissions included?
• What are the design, content and revision boundaries?
• Do integrations include data and failure behaviour?
• Who owns migration and cleansing?
• Which tests and acceptance criteria apply?
• Are security, accessibility and performance scopes clear?
• Are third-party charges separated?
• Are release, training and documentation included?
• Who owns the code, data and accounts?
• Are defects, maintenance and new development separated?
• How are changes priced?
• What costs recur, and under which renewal terms?
• Are assumptions, dependencies and exclusions visible?

Do not assess the budget in isolation. Confirm the off-the-shelf versus custom decision and the MVP scope, then map proposal items to the requirements document. The integration plan exposes third-party and failure-handling work, while the security and maintenance plan makes post-launch life-cycle ownership visible.

Conclusion

Web software cost is not only the price of writing code. Understanding the work, user experience, business rules, data, integrations, verification, release, handover and continued operation together create the budget.

Define a comparable scope before asking for one total. Compare proposals across seven budget sections, separate third-party and recurring charges, record uncertainty as assumptions and choose the commercial model according to scope maturity. You can then ask not only “Which offer is cheaper?” but “Which work, boundaries and life-cycle responsibilities are we purchasing?”