Custom software development cost: why quotes for the same system differ
Ask five vendors to price the same custom software and the quotes can be an order of magnitude apart. That spread is normal and it is measurable, and it says more about how each vendor guessed than about what your system will cost.
The short version
- There is no market price for custom software, only a price for a scope. A range published without the scope behind it describes someone else’s project.
- Wide spreads between quotes for the same brief are normal. When 46 companies estimated the same five specifications, the highest estimate for each was 14 to 64 times the lowest.
- The lowest quote is the one least likely to hold. Estimates run optimistic when price decides the winner, so choosing on price selects the most optimistic bidder.
- What you tell vendors moves the number. A stated budget or a tight deadline pulls estimates down without changing the work.
- Make quotes comparable before you compare them: the same brief to every vendor, no anchors in it, and the same seven questions to explain every gap.
There is no price for custom software, only a price for a scope
Search for what custom software costs and the answer arrives as a table of ranges by project size, with hourly rates by region underneath. In September 2026 the summary Google showed above the results cited vendor pages and forum threads for every figure in it. None of the ranges came with the scope that produced it.
A range is not so much wrong as unusable. Custom software is priced from a scope: which workflows, for which people, connected to which systems, carrying which data, held to which security and uptime standards. Change any one of those and the number changes, and two briefs described in the same words can differ in all of them. An average cost of custom software development is an average of other people’s scopes.
One disclosure before the rest. We build custom software for a living, and we do not publish prices, for the reason above. That makes us an interested party in this argument, so the evidence below comes from independent research rather than from our own projects.
Why quotes for the same system differ so much
The best evidence comes from a field experiment. Researchers at the Simula Research Laboratory in Norway paid 46 outsourcing companies in Eastern Europe and East Asia to estimate the effort for the same five software projects, from the same written requirements, and published the spread of every estimate.
| System | Highest estimate ÷ lowest | Middle half: upper ÷ lower quartile |
|---|---|---|
| System 1 | About 29 times | About 2.6 times |
| System 2 | About 20 times | About 2.4 times |
| System 3 | About 14 times | About 2.3 times |
| System 4 | About 14 times | About 1.9 times |
| System 5 | About 64 times | About 2.6 times |
Read the right-hand column first. Even with the outliers set aside, the middle half of the companies disagreed by a factor of about two on every system. Then read the middle column: in every group, one estimate was between fourteen and sixty-four times another, for identical written requirements.
Two caveats, both from the paper. The table combines companies that received the original specification with companies that received a lightly altered one, although for four of the five systems the specification was either unaltered or the alteration made little measurable difference. And the companies were told they would be judged on the quality of their estimation work rather than on price, which the authors expect made them less easily swayed than bidders in a real tender. A real procurement is unlikely to be tidier.
The spread is not dishonesty. Each vendor reads the same brief and fills its gaps differently. One assumes the data migration is clean and another assumes it is not. One prices three integrations as simple exports, another prices them as the fragile, owned, contested boundaries they usually turn out to be. A quote is a price for the vendor’s picture of your system, and the pictures differ.
The lowest quote is the one least likely to hold
Across the research on software estimation, projects overrun their effort estimates by around 30 percent on average. Magne Jørgensen’s 2014 review of the field also found that estimation accuracy had barely changed since the 1980s, despite decades of work on estimation models.
The same review pins down where the optimism concentrates. Underestimation is particularly present in price-competitive situations such as bidding rounds, while in-house teams estimating their own work show no such tendency. The implication is uncomfortable for anyone running a tender: when a buyer chooses on price, the proposals most likely to win are the ones that underestimated the work.
How the overrun arrives is predictable: change requests for things that were never in the vendor’s picture, a quality bar quietly lowered to protect the margin, or a team rotated toward better-paying work. The ERP cost article covers what the largest overruns look like in practice, and the mechanism in a custom build is the same.
None of this means the highest quote is right. It means the lowest quote needs the most explanation before it is believed.
What you tell vendors changes the number
Estimators anchor. Jørgensen’s review names the strongest influence plainly: when the people estimating know the client’s budget, expectations or available time, their estimates drift toward those numbers, usually without their noticing. Even loaded wording in a request, such as a small and simple project, pulls estimates down.
The field experiment measured one of these effects in working companies. Half of the companies estimating one system were told the client expected it built in three weeks. That should have raised their estimates, because compressing a schedule adds coordination rather than removing work. Their median estimate came in about a third lower instead. The four companies that had actually built that system before had used more effort than most of the estimates.
The other anchors tested in the field, a shorter version of the same specification and a note about the client’s low cost expectations, moved the median in the same direction but by less than laboratory studies had found. The deadline was the one effect that held its full strength outside the lab.
Three practical rules follow:
- Ask for estimates before you share a budget. Once each vendor has priced the work, the budget becomes a conversation about what to build first, which is where it belongs.
- State your deadline as the date the business needs something, and ask each vendor what they would leave out to meet it. Do not let it silently shrink the estimate.
- Take loaded words out of the brief or the RFP. Describe what the system must do, not how small it should feel.
What actually decides the cost
The number moves with the scope, and a handful of scope decisions move it most. The hourly rate is not one of them. Fred Brooks put coding in proportion in 1975: his rule of thumb for scheduling a software task gave one third of the time to planning, one sixth to coding and half to testing. Half a century of tooling has changed the ratios but not the lesson. Comparing vendors on the price of an engineering hour compares the smallest part of the work.
| Driver | What to state in your brief | Why it moves the number |
|---|---|---|
| Users and workflows | Who uses the system, and the few things each of them must be able to do | Every role and workflow is design, build and testing, and the exceptions are where the effort hides |
| Integrations | Every system it must exchange data with, and who owns each one | Each boundary is a small project of its own, and the one most often priced as an allowance |
| Data migration | What data moves across, from where, and how clean you believe it is | Migration estimates tend to assume clean data, and old data rarely is |
| Security, audit and uptime | The standards the system must meet, and who will review them | They add work to every feature rather than appearing as one line |
| Platforms | Web only, or mobile and offline as well | Each platform multiplies the build and the testing |
| What is out of scope | The things you have decided not to build yet | Unstated exclusions are how two vendors end up pricing two different systems |
| After launch | Who runs, supports and changes the system once it is live | Support is a continuing cost, and quotes differ most on whether they include it |
Integration and data deserve the most scrutiny, for the reasons set out in the two lines that decide whether an ERP number holds. They behave the same way in any custom build.
Is your brief ready to be quoted?
Tick what your brief states today. Every unticked line is a gap that each vendor will fill with a different assumption.
The questions that explain the gap between two quotes
When two quotes for the same brief are far apart, the difference is almost always in one of these seven places. Ask every vendor all seven, in writing, and put the answers side by side. The gap usually explains itself by the third.
What did you assume is out of scope?
Ask for the exclusions as a list. A lower quote often leaves out something the higher one included.
Which integrations did you price, and how?
System by system, named, with the assumption behind each: a file export, an API, or a boundary someone else owns and may change.
What did you assume about our data?
Clean or not, how much of it, and who fixes it when it turns out not to be.
How much contingency is in the number, and where?
A quote with no stated contingency has either hidden it or left it out. Both are worth knowing before you sign.
Who is on the team, at what seniority, and for how long?
Named roles and their time on the project. Two quotes can price the same hours for very different people.
What happens to the price when the scope changes?
How a change is priced tells you whether change requests are an exception or the business model.
What is included after launch?
Warranty, support, hosting, and the handover of code and documentation. Quotes differ most on what they leave out here.
Two of these, contingency and change pricing, are also the quickest way to spot the winner’s curse before you sign rather than after. An optimistic bidder has either no contingency at all or a change clause that expects to recover it.
Why we do not publish a price
Every page we read on this question publishes a range, so it is fair to ask why we do not. A range without a scope describes someone else’s project. It also anchors the reader, and the research above shows that anchoring is one of the quickest ways to an optimistic estimate, on either side of the table.
What we do instead is price the scope. We map the integration boundary and the data before we quote, which is slower at the proposal stage and considerably faster everywhere after it. The custom software development page sets out how that works, stage by stage.
When custom software is the wrong answer
Sometimes the honest answer to what custom software costs is that you should not pay it:
- A mature product already covers the process. Configure it instead, and read the build vs buy guide for where the seam between the two usually falls.
- The process is still changing. Building it now fixes the wrong shape in code, and you pay a second time to change it.
- Nobody on your side can own the scope. No quote survives a brief that nobody is authorised to decide.
Questions buyers ask about custom software cost
How much does custom software development cost?
It depends on the scope, and the honest answer is a number only after scoping. Any published range describes someone else’s project. What decides yours is the number of users and workflows, the systems it must connect to, the data it must carry, the standards it must meet, and what happens after launch.
To get a figure you can rely on, send every vendor the same brief with no budget in it, and ask each one to state its exclusions, integrations, data assumptions and contingency in writing.
Why are software development quotes so different?
Because each vendor is pricing its own picture of your system. In a field experiment where 46 companies estimated the same five specifications, the highest estimate for each was 14 to 64 times the lowest, and even the middle half of the companies differed by about two times.
The gaps come from assumptions about scope, integrations, data and contingency. Asking each vendor to state those assumptions shows where the difference lies.
Should I choose the lowest software development quote?
Not without an explanation. Research on software bidding finds that estimates run optimistic when price decides the winner, so the lowest quote is disproportionately the most optimistic one, a pattern known as the winner’s curse. Ask what it excludes and how it prices changes before you believe it.
Should I tell software vendors my budget?
Not before they estimate. Estimators drift toward any budget, expectation or deadline they are given, usually without noticing. Collect estimates on the scope first, then share the budget and use the gap as a conversation about what to build first.
What is the 40/20/40 rule in software engineering?
A rule of thumb that splits effort into roughly forty percent planning and design, twenty percent coding and forty percent testing. We could not trace it to a study. The closest published statement is Fred Brooks’s 1975 scheduling rule: one third planning, one sixth coding and half testing.
Both make the same point. Coding is the smallest part of the work, so comparing vendors on the cost of coding compares the least of it.
How can I reduce the cost of custom software development?
Reduce the scope, not the rate. Build the workflows that matter first and defer the rest, settle integrations and data before the build rather than during it, and keep one person on your side who can make decisions quickly.
Cutting testing or choosing the lowest bid tends to move the cost later rather than remove it.
Is a fixed price safer than time and materials?
Only if the scope behind it is fixed too. A fixed price on a vague brief moves the risk into change requests. A fixed price on a scoped boundary, with exclusions and change pricing in writing, is safer than time and materials billing for the same unclear scope.
How much does custom software cost to maintain?
It depends on how much the system changes after launch and on who runs it. Security patching, dependency and platform upgrades, and the steady flow of small changes a live system needs are continuing costs, whatever the build cost.
Ask every vendor what its quote includes after launch, and plan the running of the system alongside the building of it, because the total cost of ownership is decided after go-live as much as before it. The build vs buy guide covers what builders most often underestimate.
Method and sources
The claims about what published answers do and do not cover come from our own reading, so here is the method. In September 2026 we read the results search engines returned in the US for custom software development cost and how much custom software development costs, including the AI-generated summary shown above them, which cited vendor pages and forum threads for its figures. Search-result ordering is not a measured ranking position, and we make no claim about where any page ranks. The research below we read at source, and its limits are stated in the text. Everything else is judgement from scoping and building custom software ourselves, and is written as judgement rather than as data.
- The Impact of Irrelevant and Misleading Information on Software Development Effort Estimates: A Randomized Controlled Field ExperimentJørgensen and Grimstad, IEEE Transactions on Software Engineering, 2011. 46 outsourcing companies estimated the same five specifications. Source of the spread in Table 3 and of the deadline effect. The companies were judged on estimation quality, not price, so real bidding is likely to vary more
- What We Do and Don’t Know about Software Development Effort EstimationJørgensen, IEEE Software, 2014. Average overruns of around 30 percent, underestimation concentrated in price-competitive bidding, anchoring on budgets and deadlines, and the winner’s curse
- The Mythical Man-Month: Essays on Software EngineeringBrooks, Addison-Wesley, 1975. Chapter 2, the scheduling rule of thumb: one third planning, one sixth coding, one quarter component and early system test, one quarter system test. A rule of thumb from experience, not a measurement
