What determines the cost of custom software?
The cost of custom software is set not by the number of screens but by the business rules and exceptions it must enforce, the systems it connects to, the data it must migrate, its security and compliance targets, and how it will be run after launch. Most of the cost is engineering effort: person-days spent on analysis, design, development, testing, deployment and project management. Third-party costs such as hosting and licences come on top, and so does maintenance, which recurs every year after launch.
That is why "how much does an order dashboard cost?" has no single answer. Two dashboards that look alike can differ completely: one has a single approval step and connects to nothing; the other needs three approval layers, delegation rules, an ERP integration and an audit log. The screens may be similar, but the work behind the second is far larger. This article gives no prices. It explains the lines a quote is built from, how the quote is calculated and how to compare quotes.
Which factors move the cost most?
The factors that move cost most are the ones not settled in discovery that surface later: exceptions, integrations and data. The table shows why each factor raises cost and the question to ask during discovery.
| Factor | Why it raises cost | Question to ask in discovery |
|---|---|---|
| Business rules and exceptions | Every exception means separate code, tests and failure scenarios | What happens outside the normal flow: returns, partial approval, delegation, cancellation? |
| Roles and permission layers | Every role needs its own access checks and tests at screen and data level | Who sees what, who approves what, who can change what? |
| Integrations | Whether an API exists, the quality of its documentation, a test environment and the other team's availability drive the schedule | Does every system to connect have an API, a test environment and a named owner? |
| Data migration | Cleaning, mapping and reconciling old data is a job of its own | How much data moves, how clean is it, and who verifies it? |
| Security target | A higher verification level means more requirements and more testing | Which security level are we aiming for, and will there be a penetration test? |
| Accessibility | The target level affects design, component choice and testing | Which WCAG level is the target? |
| Reporting | Every report is a data model, filters and validation | Which reports are essential in the first release, and which can wait? |
| Load and uptime expectations | Concurrent users and tolerance for downtime change the architecture and hosting | How many people work at once, and how long may the system be down? |
| Hosting and environments | Cloud or on premises, the number of environments, backups and monitoring set the running cost | Where will it run, and how many environments are needed? |
| Mobile or offline use | Requires a separate app, synchronisation and conflict rules | Must people work without a connection in the field? |
| Availability on the client side | Delays in decisions and testing turn into idle time for the team | Who decides, and who takes part in testing? |
| Documentation and handover | Letting another team take over requires documents and training | Will source code, documentation and setup steps be handed over? |
How do security and accessibility targets change the cost?
Security and accessibility are not items that are simply "included" or "excluded"; they are requirements with a chosen level, and if you do not write the level down, each vendor prices a different one. OWASP's Application Security Verification Standard (ASVS) 5.0 for web applications defines three levels. Level 1 is the minimum starting point and covers around 20% of the requirements. Complying with Level 2 means meeting around 70% of them. Level 3 is for applications that need to demonstrate the highest level of security. The standard says most applications should aim for Level 2 and recommends choosing the level by the application's sensitivity and its users' expectations. Stating the target level when you request quotes is the quickest way to see whether two vendors are pricing the same security work.
Accessibility works the same way. The W3C's WCAG 2.2 recommendation defines three conformance levels: A, AA and AAA. The target level affects the design system, component choices and the test plan, and deciding it before design rather than after the software is written saves work. A public customer portal and a small internal team tool may need different targets; what matters is that the target is written down before quoting.
How is a software quote built?
A quote is built by breaking the scope into work items, estimating effort for each, adding an allowance for uncertainty and adding third-party costs. The real difference between vendors is how openly these steps are written. A sound quote makes these layers visible:
- Scope breakdown: Modules, workflows and integrations as separate lines.
- Effort estimate: Person-days or person-weeks per line, by role (analysis, design, development, testing, deployment).
- Shared work: Project management, code review, test automation, environment setup, documentation and acceptance testing. If these do not appear, they have either been spread across other lines or will not be done.
- Uncertainty allowance: An explicit range or risk allowance for items that are not yet clear.
- Third-party costs: Hosting, licences, paid services (maps, SMS, email, payments) and whose account pays for them.
- Assumptions and exclusions: The conditions under which the quote holds, and what it does not include.
The "cone of uncertainty" from the software estimation literature explains why an uncertainty allowance is unavoidable. As Construx describes it, at the initial concept stage even skilled estimators can be off by a factor of four in either direction, a sixteenfold range between the highest and lowest estimate. The cone does not narrow by itself; it narrows only as decisions about scope, requirements and interface design remove variability. For a buyer the consequence is clear: a firm figure given before any discovery either carries a large risk allowance or will be renegotiated as the project goes on.
The pricing model also decides who carries the risk:
| Model | When it fits | What the buyer should watch |
|---|---|---|
| Fixed scope, fixed price | The scope is detailed and unlikely to change | The vendor prices in the uncertainty; every change becomes a separate request and price |
| Time and materials | Scope will take shape in discovery and priorities may shift | The buyer controls the budget; regular effort reports and priority meetings are essential |
| Phased quote | Discovery first, then a narrow first release, then further phases | The buyer decides whether to continue after each phase; acceptance criteria must be written |
| Capped time and materials | Flexibility is needed, but so is a budget ceiling | Agree in advance what leaves the scope as the cap approaches |
What should you give vendors to get comparable quotes?
The most effective way to get comparable quotes is to give every vendor the same short needs document; the clearer it is, the smaller the uncertainty allowance in the quotes. You do not need a long specification. For most projects these headings are a sufficient start:
- Business problem and success measure: What will the software change, and how will you measure it?
- Users and roles: Who will use it, how many people, with which permissions?
- Today's workflow: Current spreadsheets, forms, screenshots and a list of known exceptions.
- Integration inventory: Systems to connect, their API status, test environments and owners.
- Data: Where migrated data comes from, its approximate volume, sample records and whether it contains personal data.
- Non-functional targets: Security and accessibility levels, concurrent users and tolerance for downtime.
- Hosting constraints: Cloud or on premises, and where the data must be kept.
- Schedule constraints: If there is a real deadline, the reason for it, such as a regulatory change or the start of a season.
- After launch: Who will maintain it, and during which hours support is needed.
Sharing your budget range also helps: the vendor can suggest how to solve the same problem at different budgets, and what goes into the first release and what waits. The same document becomes the input to discovery, where any missing headings are completed together.
How should you compare quotes?
Compare quotes not by their totals but by whether they cover the same scope, the same assumptions and the same post-launch obligations. The lowest total is often the quote that leaves out the most. That is not a flaw, just a different assumption, but it has to be visible. Fill in this worksheet for every quote:
| Line | What the quote should state | What happens if it is missing |
|---|---|---|
| Scope and exclusions | List of modules and workflows; what is explicitly left out | Every unclear item later becomes a change request |
| Assumptions | Whether integrations are ready, who provides test environments, the state of the data | If an assumption fails, schedule and budget change |
| Acceptance criteria | Which test accepts each phase | "Done" stays open to dispute |
| Testing | Automated tests, acceptance tests, load and security tests | Problems are found in production |
| Security and accessibility target | ASVS and WCAG levels | The quotes may be pricing different work |
| Data migration | Which data moves, verified by whom | Migration comes back as a separate project |
| Hosting and accounts | In whose name servers and cloud accounts are opened | Access problems when you change vendor |
| Source code and IP | Who owns the code and documentation | Handover and extension become harder |
| Open-source licences | Components used and their licences | Licence obligations surface later |
| Warranty and maintenance | Scope of bug fixing after launch and what the maintenance agreement covers | Maintenance becomes a separate, unexpected cost |
| Change management | How scope changes are priced and approved | Every change turns into a negotiation |
| Payment schedule | Payments tied to phase acceptance | The link between payment and delivery breaks |
Once the worksheet is filled, put the empty lines to each vendor in writing and ask for the quote again on the same scope. For questions about exit, handover and intellectual property, the points in our guide to choosing a development partner apply to non-AI software projects too.
What costs do quotes usually leave out?
The costs a quote usually leaves out begin after launch: maintenance, hosting and operations, third-party licences and services, and your own organisation's time. Asking for them as separate lines at quote stage is how you avoid a surprise at the end of the first year.
- Separate maintenance from operations: The international standard for software maintenance, ISO/IEC/IEEE 14764, defines the maintenance process and its types but leaves out operational work such as backup, recovery and system administration. Ask the two questions separately: who fixes bugs and applies security and dependency updates, and who runs the servers, backups and monitoring?
- Hosting is not one number: In the cloud, cost follows usage. AWS's Well-Architected cost optimisation principles give the example of development and test environments used only during working hours on weekdays: stopping them when idle offers a potential saving of about 75% (40 hours instead of 168 a week). The number of environments, their running hours, backup retention, log volume and outbound data transfer are what really drive the hosting line.
- Licences and services: Per-user components, commercial UI or reporting libraries, and map, SMS, email and payment services grow with usage. On-premises installations add database and operating system licences.
- Open-source obligations: Open source is free of charge but not free of conditions. Section 13 of the GNU AGPL v3, for example, requires a modified version used over a network to offer its source code to those users. Ask for a list of components and their licences with the quote.
- Your own time: The product owner's decisions, users' acceptance testing, data owners' verification and IT's access work do not appear in a quote, but they directly affect the schedule.
- Exit cost: If the code, accounts and documents are not yours, changing vendor becomes a new project.
Hypothetical example: where does the gap between two quotes come from?
This example is hypothetical and contains no figures. A distributor receives two quotes for a dealer portal where dealers place orders that flow into the ERP. Quote A's total is clearly lower than Quote B's. Once the worksheet is filled in, the picture changes:
| Line | Quote A | Quote B | Action |
|---|---|---|---|
| ERP integration | One-way transfer, assuming "the ERP API is ready" | Two-way transfer with retries on failure and a reconciliation report | Tell A in writing about the ERP's current state and the need for reconciliation |
| Data migration | Excluded | Migration of active dealer and product data | Agree who is responsible for migration |
| Security target | Not stated | ASVS Level 2 | Ask both vendors to price the same level |
| Testing | Manual acceptance testing | Automated tests plus acceptance testing | Ask which business rules automated tests will protect |
| Hosting | On the vendor's account, for a monthly fee | On the client's cloud account, set up by the vendor | Compare account ownership and exit terms |
| Maintenance | Not stated | A separate maintenance agreement with written scope | Ask A for its maintenance scope and pricing method |
Here, A's lower total is not a quality signal but a difference in scope. The buyer will still pay for part of what A leaves out: through another quote, through its own team's time, or through problems that appear after go-live. The fair comparison is to give both vendors the same scope, security target and hosting model in writing and ask for new quotes. B may still be more expensive, but you are now comparing the same work.
How can you reduce cost without lowering quality?
The lasting way to reduce cost is not to cut effort but to cut uncertainty and unnecessary scope:
- Narrow the first release: A first release that runs the single most valuable workflow end to end carries less risk than one that does a little of everything.
- Use ready-made components for standard needs: Building your own authentication, payments or notifications only makes sense with a real reason.
- Open integrations early: Have test environment access and the other system's owner confirmed before the project starts.
- Free up a decision-maker: Delays in decisions and testing become idle time, and idle time becomes cost.
- Choose the security level by risk: Not every application needs the highest level, but the chosen level must be written down.
- Run environments by usage: Stopping development and test environments outside working hours lowers hosting cost.
- Keep a change allowance: New needs appear once users see the software; an allowance set aside at the start keeps every change from becoming a crisis.
If you are considering replacing an existing system, our application modernisation decision guide covers the cost and risk difference between rewriting and renewing in stages.
How Hatson Tech prepares a quote
We do not have a price list. The first meeting and discovery are free; in discovery we map the business rules, user roles, systems to connect and data. We then quote the pilot and each later phase as a written document showing scope, deliverables, acceptance criteria and the assumptions behind them. If the scope changes, the price changes only through a written amendment, and the open-source libraries used and their licences are listed separately. You can read more about how we work on our custom software development page. If you want to clarify scope before requesting quotes, we can work through the worksheet in this article together at the first meeting.