The True Cost of ‘Cheap’ Development: You’re Buying the Wrong Thing

Every procurement exercise for software development ends up in the same place: a table of hourly rates. One supplier offers £90 an hour, another £25. The second looks like a saving of more than 70%, and it is very hard to argue with a number that big.

It is also the wrong number. You are not buying hours. You are buying finished, working software, and you are buying it so you can use it. A rate tells you the price of an hour. It tells you nothing about how many hours the work will take, how much of your own people’s time it will consume, or how long you will wait for it.

This article sets out what actually decides the cost of a development team, using the research rather than anecdote, and why the honest answer is sometimes “the cheaper team wins”. It comes with a calculator so you can test it against your own numbers.

The question a rate can’t answer

Take one piece of work: 6,400 hours of development for a team working at full productivity, or four developers for a year. Two teams can do it:

• Team A charges £25 an hour.
• Team B charges £90 an hour.

On rates alone, Team A costs £160,000 and Team B £576,000. That comparison assumes both teams turn an hour into the same amount of finished work, need the same amount of your time, and finish on the same day. None of those is likely to be true, and each one moves the answer.

What really drives the cost

1. Output per hour, not hours

The productivity of a development team is notoriously hard to measure, and it is surrounded by myth. The famous “10x programmer” comes from a 1968 experiment whose headline ratio compared the single best and worst results in a small study; a later re-analysis called it “both incorrect and misleading” Prechelt. A study of 494 developers each doing the same ten tasks found that only about half the variation came from the programmer at all; the rest was the same person’s performance varying from day to day SEI.

So this is not about talent. It is about how much finished work a team produces per hour, which depends on its experience of your kind of problem, its tools and practices, and how well it understands what you need. That figure decides the comparison, and it is the one procurement never asks for.

2. Coordination: the cost of distance

Work spread across locations is slower. In a landmark study at Lucent Technologies, Herbsleb and Mockus found that “distributed work items appear to take about two and one-half times as long to complete as similar items where all the work is colocated”, largely because distributed work involves more people who have to coordinate IEEE TSE. Time zones turn a five-minute question into a day’s wait. Handovers lose context. Each one is small; together they add up.

3. Your own people’s time

The supplier’s invoice is not the whole bill. Someone in your organisation has to specify the work, answer questions, check what comes back and decide what to do about it. A study of offshored software projects at a financial services firm found that clients carried substantial extra costs after the contract was signed, in four areas: specifying requirements and design, transferring knowledge, controlling the work and coordinating it. Those costs were highest where the work needed deep knowledge of the client’s business MIS Quarterly. Wider research on offshoring finds that firms routinely underestimate these hidden costs, and that the errors grow with the complexity of the work SMJ.

This time rarely appears in a business case, because it is spent by people who are already on the payroll. It is still real.

4. Rework

Work that is wrong has to be done again. Boehm and Basili’s widely cited summary of the evidence put avoidable rework at 40–50% of effort on typical software projects; later work found it can fall to 10–20% in the most mature organisations IEEE Computer. That range, from a fifth of the effort to half of it, is exactly the kind of difference that separates one team from another.

Poor quality also outlives the project. In a longitudinal study, developers lost an average of 23% of their working time to technical debt JSS. A cheaply built system can tax every change you make to it for years.

5. The cost of waiting

This is the one almost everyone leaves out, and it is usually the largest. You are building the system because it is worth something: savings, revenue, capacity, a better service. Every month it is not live, you do not get that value. Don Reinertsen’s work on product development makes the case for putting a price on delay and using it in every trade-off, because without one, time looks free when it is often the most expensive thing on the table.

If a slower team takes a year longer, the year of value you lost belongs on its bill.

Putting it together

Here is the same piece of work with some typical assumptions, which you can change in the calculator:

Assumption or cost	Team A	Team B
Hourly rate	£25	£90
Finished work per hour (against a fully productive team)	70%	100%
Work done again	25%	10%
Effort lost to coordination	25%	5%
Your people’s time, per week	15 hours	5 hours
Invoice	£357,143	£665,280
Goes live in	26.8 months	13.9 months
Your people’s time, at £60 an hour	£104,464	£18,018
Value lost waiting, at £50,000 a month	£646,286	£0
Total	£1,107,893	£683,298

Team A still sends the smaller invoice, by more than £300,000. But it goes live 13 months later, and once your own people’s time and the value lost waiting are counted, it costs over £420,000 more.

The most useful number is not in the table. At these rates, Team A is only cheaper if it delivers at least 92% of a fully productive team’s output per hour. Its rate is 28% of Team B’s; the bar it has to clear is nearly as high as Team B’s. That is the question to put to any supplier, and to yourself.

When the cheaper team really does win

Being honest about the model means accepting its other answers. If Team A puts eight developers on the work instead of four, it finishes first, and on the same assumptions it comes out almost £300,000 cheaper. If the work is well understood, stable and easy to specify, coordination and oversight shrink and the lower rate can win comfortably.

That matches the research. Hidden costs are highest where the work is complex, changing, or depends on knowledge of your organisation, and lowest where it is well defined and self-contained. A practical way to decide:

• Well defined and stable (maintenance of a mature system, a clearly specified component): a lower-cost team can be the right choice, provided you measure output rather than hours.
• Complex but stable (a specialist integration, a known but hard problem): pay for the specialists; they are faster, and their hours are worth more.
• Unclear or changing (a new service, a first-of-a-kind system): keep the core close, with people who can work alongside your own and challenge the brief. Here coordination costs and delay are at their highest, and a low rate is most likely to be a false economy.

What to ask before you sign

1. What will it cost to finish, not per hour? Ask for comparable past work: how big it was, how long it took and what it cost.
2. How much of our time will it take? Count the hours your own people will spend specifying, answering and checking, and put a cost on them.
3. When will it go live, and what is each month of delay worth? If you can’t put a value on a month, you can’t compare two delivery dates.
4. How will we know quality is good? Agree up front how defects, rework and delivery will be measured, and look at them every month.
5. What happens if it goes wrong? Make sure you own the code, the knowledge and the way out.

The lowest rate is easy to find. The lowest cost of getting what you need, when you need it, takes a little more work, and it is usually where the real saving is.

If you would like a second opinion on a sourcing decision, talk to us. We are independent, and we will tell you if the cheaper option is the right one.

Sources

1. Herbsleb, J. and Mockus, A. (2003). An empirical study of speed and communication in globally distributed software development. IEEE Transactions on Software Engineering, 29(6).
2. Dibbern, J., Winkler, J. and Heinzl, A. (2008). Explaining variations in client extra costs between software projects offshored to India. MIS Quarterly, 32(2).
3. Larsen, M., Manning, S. and Pedersen, T. (2013). Uncovering the hidden costs of offshoring. Strategic Management Journal, 34(5).
4. Boehm, B. and Basili, V. (2001). Software defect reduction top 10 list. IEEE Computer, 34(1).
5. Besker, T., Martini, A. and Bosch, J. (2019). Software developer productivity loss due to technical debt. Journal of Systems and Software, 156.
6. Nichols, W. (2019). The end to the myth of individual programmer productivity. IEEE Software, summarised by the Software Engineering Institute.
7. Prechelt, L. (1999). The 28:1 Grant/Sackman legend is misleading, or: how large is interpersonal variation really? University of Karlsruhe.
8. Reinertsen, D. (2009). The Principles of Product Development Flow. Celeritas Publishing.