21 October 20257 min read
A day rate is a unit price. It tells you what one day of one person costs, and it tells you nothing about how many such days you will buy, how many of them will produce work you accept, or what you will spend on your own side to make those days useful. Total cost of ownership is the discipline of answering those three questions before signing rather than after.
It is not a finance exercise for its own sake. Teams that skip it usually discover the same thing eight months in: the engagement is fine, the rate is fine, and the budget is wrong, because the budget only ever contained the rate.
Four buckets, and only one of them is the rate
- Acquisition: the time you spend finding, comparing and vetting providers, plus legal review of the contract, the data processing agreement and the IP assignment terms.
- Ramp: the period at the start where you are paying full rate for partial output, on both sides of the table.
- Running: the rate itself, plus the management, review and coordination time your own people spend every week.
- Exit: knowledge transfer, handover, documentation, access revocation, and whatever it costs to keep the work alive without the provider.
Most quotes address exactly one bucket. Most budgets copy the quote. The gap between the two is where the surprise lives, and it is almost always front-loaded and back-loaded: heavy at the start, heavy at the end, light in the middle.
The denominator problem
You do not buy output, you buy days. The connection between the two is utilisation, and utilisation is where comparisons quietly break.
Take a purely hypothetical illustration, with round numbers chosen for arithmetic rather than drawn from any market. Suppose one provider charges 100 units a day and another charges 80. If the first bills you for days actually worked on your backlog and the second bills for calendar availability including public holidays in its own country, the cheaper rate can be the more expensive year. Nothing dishonest has happened. The denominators were different and nobody said so.
The fix is to insist on the same denominator across every option you are comparing: cost per day of work delivered on your backlog. Then compare.
Rework is a cost, and it multiplies
The second denominator that matters is acceptance. A day of work that comes back for a second pass costs you the second day, the review time on both passes, and the delay to everything queued behind it. Which is why the most useful figure a mature engagement can produce is cost per accepted unit of work, not cost per day.
You cannot calculate that before you start, but you can put it in place from the beginning: agree a definition of done, track how much work is accepted on first review, and revisit the rate comparison after a quarter with the real ratio in hand. A more expensive provider with a high first-pass acceptance rate is frequently the cheaper one, and this is the specific arithmetic that proves it rather than asserting it.
Your own time belongs in the model
Every outsourced engagement consumes time from the people you already employ: specifying work, answering questions, reviewing output, running planning, and chasing the things that stalled. That time is not free, it is your most expensive time, and it is missing from the budget because it is missing from the invoice.
There is a real trade here. Staff augmentation puts more of that load on you and prices the work lower. Managed delivery moves the load to the provider and prices it higher. Comparing the two on rate alone will always favour augmentation and will frequently be the wrong answer, because the difference in rate is buying back time from people whose time costs more than the difference.
Exit is a cost even when nothing goes wrong
Engagements end. They end because the project finished, because the budget moved, because you built an in-house team, or because it did not work. In every one of those cases somebody has to hand the work over, and the cost of that handover is set years earlier by decisions that felt like process overhead at the time.
- Is the code in your repositories, under your accounts, from day one?
- Is there written documentation of decisions, or does the knowledge live in one person at the provider?
- Is IP assignment unambiguous and already executed, rather than something to negotiate at the end?
- Is there a defined notice period long enough to run a knowledge transfer, and is that transfer time billable?
An engagement that is cheap to leave is worth paying slightly more for, in the same way that a lease with a break clause is.
What the model is for
The purpose is not to produce a precise number. It will not be precise. The purpose is to make the cost structure visible, so that when the engagement is running you know which lever to pull: rate, scope, seniority mix, engagement model, or the amount of your own time being consumed.
Teams without a model respond to cost pressure by asking for a discount, which is the smallest lever available and the one most likely to damage the work. Teams with a model usually find the answer somewhere else entirely, and find it faster.