What actually drives the cost of custom software

There are no dollar figures on this page. That is deliberate, and it is not evasion. A number without the scope attached is not information — it is an anchor. You can find Australian pages quoting anything from a few thousand dollars to a million for what they each call a “departmental system”, and not one of them reconciles the spread. This page tries to do the more useful thing: teach you to read the quotes you actually receive.

By the end you should be able to tell which stage of certainty a quote came from, name the handful of factors that genuinely move effort, spot what has been left out, and narrow your own brief until the spread between quotes collapses.

Why the same brief produces several-fold different numbers

This has been measured, which is more than can be said for most claims about software pricing.

Seven teams, one specification

The data point underneath modern estimation models is a small controlled experiment: seven student teams built a product to the same imprecisely defined specification. Effort varied by a factor of about 3.4 and program size by about 3.

Two things drove that. The teams read phrases like “friendly user interface” and “single-user file system” differently. But the experiment also deliberately varied method — four teams wrote a specification first, three prototyped — and the prototyping teams produced roughly 40% less code for about 45% less effort.

Be careful what you take from it. It is a small study of student teams on a small product, so treat it as an illustration rather than a measurement of your project. What it illustrates is the point that matters: same brief, several-fold different outcome, and the difference came from interpretation and approach rather than from anyone being wrong.

Thirty-five companies, one tender

The more directly useful study is Jørgensen and Carelius’ empirical study of a real software project bidding process, published in IEEE Transactions on Software Engineering in 2004. Thirty-five companies bid for one contract against one requirements specification. Seventeen of them had first done a pre-study — a phase where they investigated the problem before giving a non-binding indication.

Two findings, and the second is the one that matters.

• The seventeen companies that investigated first bid on average about 70% higher than the ones that did not. Same specification.
• Their proposals were judged to actually meet the requirements 76% of the time, versus 50% for the others.

In the pre-study phase itself, the highest price indication was around ten times the lowest — largely because firms had different plans, some intending to use pre-made components or tailor a commercial system rather than build.

The authors’ own conclusion is worth quoting against the grain of how most people buy software: clients should not request early price indications based on limited and uncertain information when the final bids could be based on more complete information.

Which stage of certainty your quote came from

Estimation accuracy is not a matter of supplier competence. It is a function of how many decisions have been made.

The Cone of Uncertainty, which originates with Barry Boehm’s 1981 funnel curve, describes this. At initial concept, estimates by skilled estimators can be out by a factor of four in either direction — a sixteen-fold band between the high and low end. Steve McConnell’s framing of this is blunt: at that stage “it isn’t possible to be more accurate; it’s only possible to be more lucky.”

The band narrows as decisions get made. Completing requirements and user interface design reduces variability from about 4x to around 1.6x. Defining a majority of requirements up front and then iterating gets it to roughly plus or minus 25%.

Worth saying that the Cone is a widely used model rather than an uncontested law — practitioners have argued the empirical data behind it is thinner than its ubiquity suggests. Use it for the shape of the thing, which is well supported: uncertainty is highest before decisions are made, and it does not fall on its own.

This is also why a responsible supplier hesitates to give a fixed price off a one-page brief. COCOMO II, the most studied cost model in the field, deliberately produces range estimates rather than point estimates, tied to how well defined the inputs are. A precise figure from a vague brief tells you about the supplier’s confidence, not about your project.

What actually moves the effort

Here is the part that is usually missing. Every agency page lists cost factors; almost none of them says which factors matter more. A flat list implies “notifications” and “roles and permissions” weigh the same. They do not.

COCOMO II gives us published relative weights. Its Post-Architecture model uses 17 multiplicative cost drivers, each with a measured span between its lowest and highest rating. Treat the direction and rough magnitude as useful; do not treat the decimals as gospel for your project.

Two consequences worth acting on

Reliability is a business decision you are making without noticing. The difference between “if this breaks, someone is mildly annoyed” and “if this breaks, we cannot invoice” is roughly a 1.5× multiplier on effort, and you set it — not the supplier. Being explicit about which one you are buying is one of the few ways to genuinely lower a quote without cutting features.

Rushing costs money; patience is free but earns no discount. The schedule driver is asymmetric: compressing below the natural schedule pushes effort up by as much as 43%, while every relaxed schedule rating produces no modelled saving at all. So a hard deadline is a real surcharge, and a soft one is worth mentioning — not because it makes the work cheaper, but because it removes the surcharge.

What is not on this list is instructive too. Feature count is not a cost driver. The number of pages is not a cost driver. Complexity, reliability and the people doing the work are.

What the quote almost certainly excludes

One principle governs this whole section:

Silence on inclusion is read by the buyer as included, and by the supplier as excluded. Nearly every argument about software cost is really an argument about scope that nobody wrote down.

The items that recur:

• Hosting and third-party service fees. Ongoing, and yours.
• Data migration from your current system. See below — this is the one that surprises people.
• User training and documentation.
• Content and imagery. Someone has to write the words.
• Security testing beyond ordinary development practice.
• Accessibility work, if it has not been specified.
• Bug fixes after the warranty period, and the length of that period.
• Ongoing maintenance, which is nearly always separate and reasonably so.

Data migration deserves its own paragraph

Moving records is the easy half. The hard half is that years of inconsistent entry have to be reconciled: duplicate customers, three date formats, a “notes” field carrying five different kinds of information, required fields that were never filled in. Somebody has to make decisions about all of it, and that somebody usually has to be you, because only you know which record is right.

Ask directly: who cleans the data, whose hours does that consume, and what happens to the timeline if it takes longer than expected.

The long-run share

Long-standing research on software lifecycles puts maintenance at well over half of total lifetime cost — and most of that effort is changing the software as the business changes, not fixing defects. A comparison that treats the build as the cost and the run as a rounding error is comparing the wrong thing.

How to compare two quotes without a spreadsheet fight

Stop comparing totals. Normalise the assumptions first, and the totals become meaningful on their own.

Send every supplier the same five questions, in writing:

1. How many distinct user roles are you assuming, and what can each one do? Roles multiply the surface of everything — every screen, every permission check, every test.
2. Which existing systems are we connecting to, and are those integrations in your number?
3. Who migrates the data, and who cleans it?
4. What happens when the scope changes — how are change requests priced, and what is the process?
5. What is in the number and what is out? Ask for each item in the list above to be marked in or out explicitly.

The single best diagnostic question

Ask each supplier: what do you think the riskiest part of this build is?

A specific answer — naming a particular integration, a data model problem, an unclear rule in your process — means they actually looked. “Nothing much, it’s all pretty standard” means they have not found the hard parts, which is not the same as there being none. Given the pre-study finding above, this one question does more work than any amount of line-item comparison.

A quote and an estimate are different things in Australia

Worth knowing before you accept anything, though note the distinction comes from regulator guidance rather than from a definition in the ACL itself. WA Consumer Protection describes a quote as the total amount agreed for a job, given before work begins, which forms a binding agreement once accepted. An estimate is an educated guess that may end up higher or lower. Under Australian Consumer Law, a provider should use their skill and experience when estimating, and the final cost should not be much more than the amount estimated.

Also relevant: the prescribed amount is $100,000 — set by regulation 77A of the Competition and Consumer Regulations 2010, not by the text of the Act itself, which still reads $40,000 and catches people out. Below that threshold most small custom builds are acquired “as a consumer” even by a business, which brings in the guarantees of due care and skill, fitness for a disclosed purpose, and supply within a reasonable time. Section 64 makes terms excluding those guarantees void.

One important qualification: section 64A(2) still permits a supplier of business services to limit liability to supplying the services again, unless relying on that term would not be fair or reasonable. So the guarantees cannot be excluded, but the remedy can often be narrowed. Check whether the contract in front of you does that. This is general information rather than legal advice — get your own.

How to make every quote you receive tighter

You have more control over the spread than the suppliers do.

Decide things, including what you are not building

The cone narrows only when decisions eliminate variability. The most underrated move available to a buyer is writing down the exclusions — the things you have decided are not in version one. A brief that says “no mobile app, no customer self-service, no accounting integration in this phase” produces tighter and more comparable quotes than one that adds another page of features.

Be careful about leading with your budget

Research on numerical anchoring in software estimation found that telling estimators what a client considered reasonable moved professional estimates substantially — even when the estimators were explicitly told to disregard the figure.

That does not mean never share it. Sharing a budget genuinely helps a supplier shape scope to fit, which is often what you want. It does mean understanding the trade: it makes their number less independent, which matters most when you are comparing several suppliers. If you are gathering competitive quotes, hold it back; if you have chosen someone and want the best version of the thing for the money, tell them.

Do not ask for a ballpark you cannot use

This one cuts against how nearly every buyer starts, and it is the researchers’ own recommendation: do not request an early price indication based on limited information when a better-informed price is available later. An early number is not free — it becomes the anchor everyone argues against for the rest of the project, including you.

When the cheap quote is right, and when not to build at all

Nothing above should be read as “pay more.”

Sometimes the low number is simply correct. A small, stable, genuinely understood brief costs less to build, and a low price can reflect low uncertainty rather than low diligence. The pre-study research says investigate first — it does not say the expensive bid is always right.

If your process is ordinary, off-the-shelf will usually beat custom on both cost and risk. Custom earns its keep where the process is genuinely yours — where the way you do the thing is the reason customers choose you. If you cannot name what your business does differently, that is a strong signal to buy a product.

The largest saving available to most buyers is not a cheaper supplier. It is building less. Cutting scope reduces cost roughly proportionally and reduces risk more than proportionally, because the parts you did not build cannot be late, wrong, or in need of maintenance.

And a point that can argue against us: a quote from a small specialist team and a quote from a thirty-person agency are not the same product at the same price. Bench depth and continuity have real value. If your system will be load-bearing within weeks, that difference is worth weighing rather than optimising away.

One more thing: the AI discount

Suppliers, including us, build with AI tooling now. It is reasonable to ask whether that should make your project cheaper.

The most-cited evidence here is METR’s randomised trial, and it is worth reporting properly rather than as the headline it became. In the July 2025 study, 16 experienced open-source developers completed 246 real tasks on codebases they knew well. They forecast a 24% speedup, believed afterwards they had been 20% faster, and were measured as 19% slower.

That result has since been revisited. In February 2026 METR published a revised experiment design covering 57 developers across 143 repositories and more than 800 tasks. The measured slowdown was much weaker — about 4% for new participants, with a confidence interval spanning roughly −15% to +9%, so the effect is no longer clearly distinguishable from zero. METR’s own view is that developers are likely more sped up in early 2026 than their 2025 estimates suggested.

So the honest summary is not “AI makes developers slower”. It is that the measured effect is far smaller and far less certain than the confidence with which it gets quoted in either direction, and that the gap between how fast developers felt and how fast they were is the finding that has held up best.

The practical question to ask a supplier: what happens to the price if the expected saving does not arrive?

Common questions