What Custom Software Actually Costs

Search for what custom software costs and you will find dozens of confident answers. An MVP is $15,000 to $150,000. A mobile app is $50,000 to $250,000. An enterprise platform starts at $500,000.

We went looking for the source of those numbers.

There isn't one.

Every banded figure in circulation originates on a software agency's own marketing page, with no disclosed sample, no methodology and no data source. They are house numbers — what that firm charges, or would like to charge, generalised into the appearance of a statistic. Repeat one often enough across enough websites and it starts to look like industry knowledge.

Here is what genuinely exists, and precisely what each thing can and cannot tell you.

Government contract awards are real records of prices actually paid — USAspending.gov in the US, Contracts Finder and Find a Tender in the UK. But public sector software carries security clearance, accessibility compliance and procurement overhead that make it a poor proxy for commercial work.

ISBSG, the International Software Benchmarking Standards Group, is a nonprofit whose repository holds 13,147 development and enhancement projects submitted by IT organisations. Its data measures project size in function points and effort in hours — not price. It is a paid subscription product, and while its partner network includes national software metrics associations it also includes commercial estimation vendors, so "independent" deserves an asterisk.

COCOMO II is real, peer-reviewed parametric estimation. It outputs person-months from size and complexity inputs. Converting that to money reintroduces the same guesswork one level down.

So nobody can tell you what your software will cost. What we can do is show you how to build the number yourself, from inputs you can verify — and how to check whether a quote in front of you is coherent.

Start from labour, because that is what you are buying

Software cost is overwhelmingly people cost. Everything else is rounding.

The US Bureau of Labor Statistics measures software developer pay through an establishment survey, estimating employment at 1,687,890. As of May 2025, the median hourly wage for software developers was $65.38 and the mean annual wage $148,100. The spread is wide: 10% of developers earn $82,460 a year or less, and 10% earn $214,670 or more. (BLS Occupational Employment and Wage Statistics; percentiles from the occupation profile)

That is salary, not cost. An employer pays considerably more than a wage.

BLS measures that gap too. In its June 2026 Employer Costs for Employee Compensation release, private industry total compensation averaged $46.89 per hour worked, of which wages were $32.82 and benefits $14.07 — benefits at 30% of the total. (BLS ECEC)

That gives a multiplier of roughly 1.43× wages.

One caveat, and it matters: ECEC measures compensation only — wages, benefits and legally required contributions. It excludes office space, equipment, software licences, recruiting, management overhead and non-billable time. So 1.43× is a floor on fully loaded cost, not the whole of it. Anyone quoting a 2× or 2.5× multiplier may well be right, but they owe you the reasoning, because the published data does not get them there on its own.

Offshore and nearshore rates are a different matter, and here the honesty problem returns. No government or statistical agency anywhere publishes developer billing rates — rates are a commercial construct, and the only people who publish them are the people selling the hours.

Accelerance, an outsourcing brokerage, surveys its partner firms and reports senior developer rates of roughly $31–41 per hour in Asia, $60–75 in Latin America and $64–76 across Europe, with Central and Eastern Europe at the lower end of that European band. Clutch, a marketplace funded by provider listings, reports most listed firms charging $25–49 per hour. Its stated average project cost is $132,480 — but the same page says the typical custom software project falls between $10,000 and $49,999, so that average is roughly three times the modal band and is being pulled by a long tail.

Use all of this as asking prices from self-selected vendors, which is what it is. Not as measurements. Clutch is explicit that its country rankings reflect its own site traffic rather than any sample of the market.

Build the estimate, then test it

With a loaded cost per person-month, the arithmetic is straightforward. What is not straightforward is the team composition, and this is where most quotes quietly mislead.

A functioning software team is not a stack of developers. It typically includes engineering, a technical lead, someone accountable for product decisions, quality assurance, and design. Quality assurance analysts have a mean annual wage of $111,490 in the same BLS data — cheaper than developers, but not free, and a quote with no QA line is not a cheaper quote, it is an incomplete one.

Then apply the multiplier the industry does not like to mention. DORA's research found that even elite-performing engineering teams report spending only about 50% of their time on new work, the rest going to unplanned work, rework, defects and support. Low performers report 30%. (DORA, 2018 State of DevOps)

If your estimate assumed a team would spend its working week building the thing you asked for, it is out by a factor of two before anyone writes a line of code.

Now test the result against what is known about how estimates behave. The largest peer-reviewed study of IT project costs collected 5,392 projects completed between 2002 and 2014, of which 4,677 had usable cost data. Across those, the median cost overrun ratio is 1.0 — the typical project lands on budget — while the mean is 1.8, because overruns follow a power-law distribution with a very long tail. The authors note their own limitations plainly: organisations willing to share data probably outperform those that are not, and terminated projects were excluded, so the real picture is likely worse. (Journal of Management Information Systems, 2022)

The same study tested whether small projects are safer. They are not: differences between the power-law tails across project sizes were not statistically significant (p = 0.863), and the largest overrun in the dataset — 280 times its estimate — was a $1,500 workflow customisation.

So a sensible estimate is not a single number with 20% added. It is a central figure you expect to hit, plus an explicit statement of what would have to go wrong to breach it badly, plus a checkpoint that would catch that early.

The build is the deposit, not the price

The largest error in software budgeting is not underestimating the build. It is treating the build as the cost.

The US Government Accountability Office reports that of the more than $100 billion the federal government spends annually on IT and cyber-related investments, agencies have typically reported spending about 80% on operations and maintenance of existing IT rather than on building anything new. (GAO-25-107795)

That is a portfolio figure for a very old estate, not a rule about your project. The often-quoted "60–80% of software lifetime cost is maintenance" has a thinner basis than its popularity suggests: the most quotable source is Robert Glass in IEEE Software in 2001, who actually wrote 40 to 80 percent, 60 percent average — and wrote it in an opinion column that cites no source. (IEEE Software, 2001)

We use 40–80% as a planning range and we say where it comes from. What matters is that the line exists in your budget at all. It should include:

• Hosting and infrastructure, which grow with usage rather than staying flat
• Dependency maintenance — the libraries your software is built on will publish security updates, and somebody has to apply them
• Support, whether that is a person or a rota
• Change, because the business will change and the software will need to follow
• Eventual replacement, which arrives sooner than anyone plans for

Technical debt belongs here too. In 2020 McKinsey surveyed 50 CIOs at financial services and technology firms with revenues above $1 billion, who estimated technical debt at 20–40% of the value of their entire technology estate before depreciation, with 10–20% of the budget for new products diverted to resolving debt-related issues. Small sample, two sectors, self-estimated — but it points the same way as the developers themselves: in Stack Overflow's 2024 survey, 62.4% of the 28,251 professional developers who answered that question named technical debt as a frustration at work, the most-selected answer by a wide margin. (McKinsey, Stack Overflow)

Debt is not an abstraction. It is a standing charge against future capacity, and it compounds.

The cost of leaving

One line that almost never appears in a business case: what it costs to stop.

The UK Competition and Markets Authority investigated the cloud services market for nearly two years and concluded in July 2025 that "competition is not working well." Its most striking finding: "less than 1% of customers switch provider each year." The CMA named egress fees — charges to move your own data out — as a key commercial barrier, and found the technical and commercial barriers together "lock customers into their initial choice of provider." (CMA)

This is changing, but only in one jurisdiction. Under Article 29 of the EU Data Act, switching charges are capped at directly-incurred cost and prohibited entirely from 12 January 2027. (Regulation (EU) 2023/2854)

Ask the exit question at the start, when you have leverage, rather than at the end, when you do not.

How to read a quote

Four tests, in order of how much they reveal.

Does the quote show its assumptions? Team composition, seniority mix, duration, loaded rate. A single number with no workings is not an estimate. It is a position.

Does it include the running cost? If year one is the only year priced, you are looking at a deposit.

Does it name a failure mode? Ask what would make this cost three times more, and what checkpoint would catch it. A supplier who has delivered at scale can answer immediately. One who cannot has either not thought about it or does not want to say.

Does it tell you what it costs to leave? Data formats, repository access, documentation, transition support. If nobody can answer, that is the answer.

What we do

We quote the running cost alongside the build, because a number that stops at launch is not a cost. We state our assumptions — team, rates, duration — so you can challenge them rather than accept them. And we write the exit into the start: your data, your repositories, your documentation, in portable formats, on request, without a commercial conversation attached.

If you are sizing a project and want the numbers examined properly before anyone builds anything, that is a conversation we are glad to have.

Kaizen Spark Tech designs and delivers software, AI, automation and digital infrastructure for businesses and institutions. Every statistic here is linked to its original published source, with its sample size and limitations stated where they matter. Where a widely-quoted figure turned out to have no traceable source, we have said so rather than repeated it. If you find something here we have got wrong, tell us and we will correct it in public.