Cost is mostly people’s time
“How much will it cost?” is usually the first question about a new application, and the honest answer is “it depends on what you need it to do”. That is not evasion. The cost of custom software is driven largely by the effort of skilled people: analysts, designers, engineers, testers and the people who deploy and run the system. Hosting, licences and third-party services add to it, but the effort of designing, building, testing and maintaining the software is where most of the variation between projects comes from.
So the useful questions are what drives that effort, and how anyone can estimate it before the work is done. This guide covers both, without quoting price figures, because any figure that ignores your specific scope would be meaningless.
The main cost drivers
1. Scope and functional size
The single biggest driver is how much the software has to do: the number of user journeys, screens, business rules, reports, roles and integrations. More functions mean more design, code and testing.
Functional size can be measured formally. The COSMIC method, recognised as ISO/IEC 19761:2011, measures software size from its functional requirements and is used as a basis for estimating effort and measuring productivity, independent of programming language or methodology. Even if you never run a formal count, the idea is useful: cost scales with what the system must do, not with how impressive the idea sounds.
2. Complexity and uncertainty
Two features with the same number of screens can differ widely in effort. Complexity comes from:
- Business rules with many exceptions, such as pricing, eligibility or approval workflows.
- Integrations with payment gateways, ERPs, government systems or legacy databases, especially when documentation is poor or test environments are unavailable.
- Data migration from older systems, where cleaning and mapping data often takes longer than expected.
- New or unproven technology, where the team has to learn and experiment.
Uncertainty is closely linked. Where requirements, data or third-party behaviour are unknown, effort is harder to predict and any estimate needs a wider range.
3. Quality attributes
Non-functional requirements are often invisible in a feature list but significant in effort:
- Security: authentication, authorisation, encryption, audit logs, security testing.
- Performance and scale: caching, load testing and capacity planning for expected peaks.
- Availability: redundancy, backups, monitoring and recovery procedures.
- Accessibility: design and testing so people using assistive technologies can use the product.
- Compliance: privacy, data retention and sector-specific obligations that shape design and documentation.
Higher targets in any of these increase effort. Stating them early prevents expensive rework later.
4. Platforms and devices
A responsive web application, native Android and iOS apps, a cross-platform app, an admin console and a public API are each separate deliverables. Each additional platform adds design, development, testing and release work, as well as ongoing compatibility updates.
5. Team, process and change
The mix of roles, the experience of the team, and how decisions are made all affect cost. Slow feedback, unavailable decision-makers and unclear ownership add idle time and rework.
Change is normal. The Agile Manifesto’s principles explicitly welcome changing requirements, even late in development. Welcoming change does not make it free, though: every change to agreed scope has a cost, and a good engagement makes that cost visible so that it can be traded off against other work.
6. Running costs after launch
Development is only the first part of total cost of ownership. After launch you pay for:
- Hosting and cloud services, which vary with usage. Provider tools such as the AWS Pricing Calculator help model this before you build; AWS notes that its estimates exclude applicable taxes and cover only the configuration you enter.
- Third-party services and licences: maps, SMS, email, payments, monitoring.
- Maintenance: security patches, dependency and platform upgrades, bug fixes and small enhancements.
Technical debt affects these costs directly. Martin Fowler describes technical debt as internal quality problems that make every later change take longer, with the extra effort acting like interest on a loan. Cutting corners to lower the initial price often raises the cost of every subsequent feature.
How software estimates are made
No single method is reliable on its own. Experienced teams combine several and compare the results.
Bottom-up estimation from a work breakdown
The work is broken into small, well-understood tasks, each task is estimated by the people who will do it, and the results are added up with allowances for testing, integration, project management and deployment. This is detailed and transparent, but only as good as the breakdown; anything left out of the list is left out of the estimate.
Analogy and historical data
The new project is compared with completed projects of similar type and size, adjusting for differences. This is fast and grounded in reality, provided the reference projects really are similar and their actual effort was recorded.
Functional size measurement
A formal size count (such as COSMIC) is converted to effort using productivity data from comparable work. It is more objective than judgement alone, but needs reasonably complete requirements and good historical data.
Relative sizing in agile teams
Agile teams often size backlog items relative to each other rather than in hours, then use their observed delivery rate to forecast. The Scrum Guide is clear that the Developers who will do the work are responsible for sizing, and describes refinement as an ongoing activity that adds detail, order and size to backlog items. Forecasts improve as the team builds a track record.
Ranges rather than single numbers
Whatever the method, an honest early estimate is a range. One common technique is to ask for optimistic, most likely and pessimistic values for each item, which makes the uncertainty explicit rather than hiding it inside one figure. The range should narrow as discovery, design and early delivery answer the open questions.
What makes an estimate trustworthy
The US Government Accountability Office’s Cost Estimating and Assessment Guide (GAO-20-195G, March 2020) is written for large public programmes, but its process applies to software of any size. Its key steps include defining the estimate’s purpose and scope, describing the technical baseline, building a work breakdown structure, recording ground rules and assumptions, collecting data, choosing estimating methods, carrying out sensitivity and risk analysis, documenting and presenting the results, and updating estimates with actual costs.
In everyday terms, a reliable estimate:
- States exactly what is in and out of scope.
- Lists its assumptions, such as who provides content, which APIs are available, and how quickly feedback is given.
- Shows how it was produced, not just the total.
- Identifies the biggest risks and how they could move the number.
- Is revisited as real progress data arrives.
An estimate that arrives as one number with no assumptions should be treated with caution, whether it is high or low.
Why estimate at all?
Fowler makes the point in The Purpose of Estimation that estimation is valuable when it helps make a significant decision, such as choosing between options or coordinating dependent teams. Knowing which decision an estimate supports tells you how precise it needs to be. A go/no-go decision on a new product needs a credible range; planning next fortnight’s work needs a much finer view.
Pricing models and how they share risk
How a project is contracted changes who carries the uncertainty:
| Model | How it works | Works best when |
|---|---|---|
| Fixed price | An agreed scope for an agreed price | Scope is small, stable and well specified |
| Time and materials | You pay for the effort actually spent | Requirements will evolve or discovery is needed |
| Dedicated team | A team works on your product for an agreed period | You need sustained, flexible capacity |
| Phased | A priced discovery phase, then delivery estimated from its outputs | The idea is clear but details are not |
Fixed price moves risk to the supplier, who will include a margin for it and will manage change formally. Time and materials keeps flexibility but needs active scope and budget management from you. Many organisations use a short, fixed discovery phase to reduce uncertainty before committing to a larger budget.
How to get a more reliable quote
You can narrow any estimate by giving suppliers better input:
- Describe the problem, the users and the outcomes you need, not only a feature list.
- Separate essential features from desirable ones.
- List every integration, with documentation where available.
- State non-functional needs: expected users, availability, security, accessibility and compliance.
- Describe existing systems and data that must be migrated.
- Say who will host, support and maintain the software after launch.
- Ask each supplier for their assumptions, exclusions and risks, and compare those as carefully as the totals.
Clear inputs will not make software cheap, but they make its cost predictable, and predictability is what lets you plan.